How to run a sprint retrospective

Most retrospectives produce a list nobody looks at again. The format below is built to produce the opposite: a small number of changes with names against them.

Start with the Prime Directive

Read it out loud before anything else:

This is not a formality. It is the difference between a team examining a system and a team quietly deciding whose fault the sprint was — and people can tell within the first two minutes which kind of meeting they are in.

The five phases

The structure comes from Agile Retrospectives (Derby & Larsen), and it works because each phase does one job and hands off cleanly to the next.

1. Set the Stage
   Get everyone present, and make it safe to be honest.
   Read the Prime Directive aloud. Run the check-in and safety poll before anything else — people who have not spoken in the first five minutes often do not speak at all.
2. Gather Data
   Collect what actually happened, before anyone interprets it.
   Keep cards hidden while people write. Seeing someone else’s card first is enough to change what you write — that is anchoring, and it quietly shrinks the range of what gets said.
3. Generate Insights
   Find the themes and agree what matters most.
   Group duplicates first, then vote, then discuss only the top few. Discussing every card is the most common way a retro runs out of time before deciding anything.
4. Decide What to Do
   Turn the top themes into a small number of owned experiments.
   One to three actions, each with a named owner and a date. An action owned by "the team" is owned by nobody. Fewer actions that actually happen beat a long list that does not.
5. Close the Retrospective
   Confirm the actions and check the retro itself was worth the hour.
   Read the actions back, then collect ROTI. If people rate the session poorly, that is data about your facilitation — ask what would have made it a 5.

Everyone writes before anyone reads

This is the single change that most improves a retrospective, and it costs nothing.

If cards are visible as they are written, the first card sets the agenda. Everyone else anchors on it — writing variations of what is already there, or quietly deciding their own point is too small to add. You end up discussing whatever the fastest typist happened to care about.

Keep the cards hidden until everyone has finished, then reveal them all at once. You will get a wider spread of problems, and the quiet people will have contributed something before the discussion starts rather than after it has already settled.

Vote before you discuss

A wall of thirty cards is not an agenda. Group the near-duplicates first — three cards about slow code review are one theme, not three — then give everyone a small number of votes, three or so.

The budget is the point. With ten votes people vote for everything and the result is flat. With three they have to choose, and what surfaces is what the team actually wants to spend the hour on.

Actions, not resolutions

An action a retrospective can actually deliver has three properties:

• A named owner. Not "the team". Actions owned by everyone are owned by nobody, and this is the most common reason retro actions quietly die.
• A date. "Before the next retro" is a real deadline. "Soon" is not.
• It is small. "Improve our testing culture" is a wish. "Add a smoke test to the deploy pipeline" is an action.

Aim for one to three. Then open the next retrospective with them — reviewing last time's actions out loud is what makes a team believe the meeting is real. Skip it twice and people learn, correctly, that the actions never mattered.

Check the retro itself

End with an anonymous ROTI score — return on time invested, one to five. Nobody tells a facilitator to their face that the last hour was a waste, which is exactly why it is worth asking anonymously. A low score is useful information, not a failure; ask the team what would have made it a five while they still remember.

What goes wrong

• Discussing every card. The commonest way a retro runs out of time before deciding anything.
• Too many actions. Eight actions is a way of avoiding choosing.
• Never revisiting. If last sprint's promises are not mentioned again, people stop making them.
• Ignoring low safety. Digging into problems in a room that does not feel safe produces silence, or blame. Fix that first.
• The same format forever. Rotate the template — a different question gets different answers.

Common questions

How long should a sprint retrospective be?

About an hour for a two-week sprint. Longer usually means the team is discussing every card rather than the few that matter.

Who should attend a retrospective?

The people who did the work. Adding managers who were not in the sprint changes what people are willing to say.

What if nobody says anything?

That is usually a safety problem. Have everyone write privately first, and run an anonymous safety check — if it is low, spend the session on that instead.

How many actions should a retrospective produce?

One to three, each with a named owner.

Next: Retrospective templates — six formats and when each one is the right question to ask.