How to Run a Sprint Retrospective That Actually Improves Things

2026-07-22 · 7 min read · Tools & Productivity

The sprint retrospective has a reputation problem. Ask most engineers what they think of it and you'll hear some version of: "We do it, we write things on sticky notes, and then we do the same things next sprint." The meeting exists, the motions are gone through, and nothing changes.

The retrospective is supposed to be the team's best mechanism for self-correction. When it works, it's the meeting where the team gets measurably better, sprint by sprint. When it doesn't, it's an hour of mild catharsis that produces zero lasting change.

The difference isn't the format. It's whether the retrospective creates real decisions that actually get executed.

Why Most Retrospectives Fail

The feedback is too vague. "Communication could be better" is not an action item. It's a mood. Vague feedback leads to vague follow-through, which leads to the same issue appearing in next quarter's retro.

Action items don't have owners. "We should improve our deploy process" is not an assignment. "Rohan will document the manual steps in the deploy process and propose an automation by the next sprint" is. If an action item doesn't have a name next to it, it doesn't exist.

Nobody follows up. If the first five minutes of the next retro aren't spent reviewing what was committed to last time, the team learns implicitly that commitments don't matter.

The same issues keep appearing. When the retro consistently produces the same themes ("unclear requirements", "too many interruptions", "PR review is slow"), either the team isn't actually addressing the root causes, or the action items aren't getting done. Both are signals that the format isn't working.

It's not psychologically safe. If the EM is defensive when problems are raised, or if naming an issue is risky politically, people stop raising real issues and the retro becomes performance. Psychological safety is the prerequisite for an honest retrospective.

The Right Structure

A good retrospective has four components, in this order:

1. Review Last Sprint's Commitments (5–10 min)

Before gathering new feedback, look at what you committed to last time. One by one:

This is the most skipped step in retrospectives, and the most important. It signals that commitments mean something. It surfaces systemic problems (action items keep getting dropped because they're never actually prioritised). And it prevents the same issues from appearing as "new" feedback every sprint.

2. Gather Data (15 min)

The classic "what went well / what didn't / what should we try" format works. So does "glad / sad / mad", DAKI (drop / add / keep / improve), or a simple timeline of the sprint.

What matters more than the format:

Give people time to write before they share. Silent individual brainstorming for 5 minutes before group discussion produces more honest output than open discussion, which is dominated by whoever speaks first.

Group similar themes before discussing. When 8 people have written 3 items each, you have 24 pieces of feedback. Grouping them into themes (3–5 usually) makes the discussion manageable and reveals what's actually common.

Don't spend discussion time on things in the "what went well" column. Acknowledge them briefly. Spend your time on what needs to improve.

3. Identify Root Causes (10–15 min)

For each major theme in the "what didn't go well" section, spend a few minutes asking why it happened — not just what happened.

The "five whys" technique works here: take the stated problem and ask why it occurred. Then why that. Usually within three or four iterations you arrive at something more actionable than the original complaint.

Problem: "We shipped the feature with a bug that affected 3% of users." Why: "We didn't catch it in QA." Why: "The test environment didn't have the same data setup as production." Why: "We don't have a documented process for seeding test data for new features." Root cause: Missing documentation / tooling for test data setup.

Now you have something specific to fix, not a vague "be more careful in QA."

4. Choose Commitments (10 min)

This is where most retros go wrong. The team brainstorms 12 action items and commits to all of them. Next sprint, none get done because they were never actually prioritised.

Choose one to three things maximum. Not because the other things aren't real, but because a team can only genuinely absorb one or two changes per sprint. Items that don't get picked go into a running backlog — they don't disappear, they wait.

For each commitment:

"We should improve our test coverage" → "Maya will add test coverage for the checkout flow to > 80% by the end of the next sprint."

That's a commitment. The vague version is a wish.

Facilitation Tips

Rotate the facilitator. You running every retro has two costs: engineers don't develop facilitation skills, and the dynamic of you-as-manager is always present. Senior engineers facilitating their own team's retro is healthy.

Don't make it about you. Your job in the retro is to ask questions and protect the space, not to make announcements or steer toward conclusions you've already reached. If you're talking more than 30% of the time, you're facilitating wrong.

Call out the elephant in the room. If there's an obvious thing nobody is saying — a deployment failure last week, a scope change that upset the team, a specific interpersonal tension — name it. "There's something I'd like to put on the table if nobody else is going to: the Tuesday incident. I think we should talk about what we could have done differently." Retros where the main problem is avoided are worse than no retro.

Be careful with voting. Dot voting (where everyone votes on which themes to discuss) is efficient but can suppress minority concerns. Sometimes the thing only two people flag is the most important thing. Use voting as a signal, not a gag.

The Retrospective Retrospective

Every quarter or so, step back and look at the meta-level: how is the retrospective itself working?

If the retrospective is producing the same output cycle after cycle without visible change, the problem isn't the team. It's the format or the follow-through. Change something — the facilitator, the structure, the frequency, the way you track commitments. A broken retrospective is worse than none, because it wastes time and erodes trust in the team's ability to improve.

Remote Retrospectives

Remote retros require more structure than in-person ones. Without shared physical space, the informal side-conversations that often surface the most honest feedback don't happen.

Use a virtual whiteboard tool (Miro, FigJam, or a simple shared doc) for the brainstorming phase. Give even more time for individual silent writing — 7–8 minutes — before group discussion. Check in on quieter team members explicitly: "Priya, I haven't heard from you on this theme — any thoughts?"

The 1:1 before a retro is a useful pressure valve for remote teams. If you know there's something a team member wants to raise but won't in a group setting, you can find a way to surface it anonymously or broaden the theme so it can be addressed.

The Underlying Goal

The retrospective isn't a ritual to get through. It's the team's formal mechanism for deciding what to change. Every team has things that could be better — ways of working, tooling gaps, communication patterns, team norms. The retro is the scheduled time to name those things and commit to addressing one of them.

Done consistently, a team that takes retrospectives seriously gets measurably better each quarter. Not dramatically — one small improvement at a time. But one real improvement per sprint over a year is a meaningfully different team than you started with.

That compounding effect is the reason the retrospective exists. Make it earn its hour.

Track team goals, 1:1 notes, and commitments across sprints in one place. Try Emtricks free for 30 days — no credit card required.