Sprint Retrospective: How to Run One That Changes Something

TL;DR

• A sprint retrospective exists to improve how the team works. It is not a review of what the team built.
• The standard shape is five phases: set the stage, gather data, generate insights, decide what to do, close.
• An hour, for a two-week sprint. Three hours is the Scrum Guide’s ceiling, not a target.
• One or two improvements per retrospective is plenty. A list of twelve is how nothing happens, because no single item is anybody’s job.
• When the same issue returns every sprint, either nobody owns the fix or the cause sits outside the team.

Most writing about the sprint retrospective is aimed at the person filling in the template. This is aimed at the person running the room, because that is the job that decides whether the hour is worth anything.

I am a facilitator rather than a Scrum Master, and after 800-plus events I will say this with some confidence: the format matters far less than the first five minutes and the last five. Teams do not go quiet because they have nothing to say. They go quiet because nobody made it safe, or because the last four retrospectives changed nothing.

What is a sprint retrospective, and what is it for?

A sprint retrospective is the meeting at the end of a sprint where the team inspects how it worked and commits to changing something. The Scrum Guide states the purpose as planning ways to increase quality and effectiveness, with the team inspecting individuals, interactions, processes, tools and its Definition of Done.

The useful distinction is with the sprint review. A review looks at the product with stakeholders present. A retrospective is the team inspecting interactions and process, and its purpose is explicitly not outcomes. Mix the two and you get a status meeting with feelings attached.

None of this is new. The twelfth principle of the Agile Manifesto asks teams to reflect at regular intervals and adjust accordingly. The word itself reached agile through Norman Kerth, whose 2001 book popularised it over bleaker options like post-mortem.

What does a good sprint retrospective look like?

A good sprint retrospective moves through five phases rather than one open question. Esther Derby and Diana Larsen set out the five phases that most facilitators now work from: set the stage, gather data, generate insights, decide what to do, close.

Skip a phase and you can feel it. Skip gathering data and the loudest memory wins. Skip insight and you fix symptoms. Skip the decision and you have run a support group.

Here is how I would spend an hour:

Retromat, the plan generator most teams eventually find, picks one activity per phase. That is a sound design rule even if you never use it.

Set the stage: the first five minutes

Open by getting every voice into the room. One word each on how the sprint felt will do it. Say nothing clever yourself.

Then read Kerth’s prime directive out loud: everyone did the best job they could, given what they knew at the time, their skills, the resources available and the situation at hand. It sounds pious written down. Said aloud in a tense room it does real work, because it takes blame off the table first.

How long should a sprint retrospective be?

An hour, for a two-week sprint. The Scrum Guide caps the event at three hours for a one-month sprint and notes shorter sprints usually need less. The Agile Alliance glossary puts the range at one to three hours, and Atlassian’s play budgets 60 minutes for four to eight people.

Treat three hours as a ceiling you will rarely touch. A retrospective is an all-hands meeting, so its real cost is the hour multiplied by everyone in it. Thirty minutes is enough if the team is small and the sprint was calm.

Which retrospective formats actually work?

The ones that make people write before they talk. Simple two or three column prompts carry most of the load: what went well, what did not, what we will change. Atlassian’s 4Ls asks what people loved, loathed, learned and longed for, which gets at feeling rather than process and suits a team that has gone flat.

Timeline formats work when the sprint had a clear event in it, a release or an outage. Put the two weeks on a wall, mark the moments, then ask what each taught you. The sailboat and the starfish are variations on one mechanic, and swapping one in every few sprints keeps attention.

Writing first is the part I would not drop. It is why a show of hands tells you nothing: whoever speaks first sets the frame, and quieter people edit themselves to fit it.

Which formats go stale, and why?

Any format goes stale when it becomes the point. Atlassian put it bluntly: retros turn into check-the-box exercises that serve no purpose. The tell is the same four sticky notes in the same three columns, week after week.

Novelty is not the fix. What goes stale is not the template, it is the absence of consequence, and a team can tell the difference immediately.

Two things keep a format alive. Change the focus rather than the game: one week look only at handovers, the next only at testing. And start every retrospective with last time’s actions, out loud, done or not done.

Why does psychological safety decide the whole meeting?

Because an effective retrospective requires that everyone feels comfortable speaking up, and the facilitator is responsible for creating that condition. The Agile Alliance glossary is direct about the awkward part too: a manager in the room may inhibit any discussion of performance.

So decide deliberately who attends. If the line manager must be there, they speak last and least. Watch for the usual patterns of reading the room: the person who has stopped offering anything, the one who answers everything.

In my experience of corporate rooms, cringe rather than reluctance is what kills participation. People will say difficult things readily if the format removes the risk of looking foolish in front of colleagues. Anonymous written input, silent sorting and pairs before plenary are all in service of that.

What do you do when the same issue comes back every sprint?

Stop treating it as a retrospective item and treat it as a diagnosis. Identical issues recurring without measurable improvement may signal that the retrospective has become an empty ritual, and that is a harder conversation than any sticky note.

Work through it in three steps.

First, check ownership. An action with a team’s name on it has nobody’s name on it. Give each change one owner and one sprint.

Second, go after the cause. The 5 Whys practice from Toyota exists for exactly this: ask why until you are past the symptom. Taiichi Ohno’s example runs from a blown fuse down to a missing strainer, and his point is simple. Without those questions you replace the fuse and the failure recurs.

Third, be honest about scope. Some causes sit above the team: a dependency, a staffing gap, a deadline nobody in the room set. Those belong in a written escalation, named and costed, and the retrospective’s job is to produce it rather than re-litigate it fortnightly. Fewer owned changes beat a long list, and one or two ideas per retrospective is the glossary’s own advice.

Running a retrospective with a big group

Everything above assumes eight people or fewer. The standard retrospective was designed for twelve people in a room, not for a hall, and above about a dozen a single conversation becomes a queue.

Split it. 1-2-4-All runs the same question alone, then in pairs, then in fours, before surfacing what survived to the whole group. Everyone contributes and nothing depends on confidence. The wider family of liberating structures is built on that principle, and for a programme-level retrospective it is the only approach I have seen hold up.

At that size there is a case for an independent facilitator. Not for the technique, which a Scrum Master already has, but because somebody with no stake in the answer can ask what nobody internal can.

Close it properly

End on the two things people will remember: what we decided, and who is doing it. Say both out loud. Write them where the team will see them tomorrow, not in a document nobody opens.

Then take thirty seconds on the meeting itself. One word each on how useful that hour was. It feels like a formality and it is the best early warning that the ritual is dying.

One owned change per sprint, every sprint, compounds quietly into a team that is hard to beat. It is the same reason a project kick off meeting earns its hour. The meetings that bookend the work are the cheapest places to change how the work goes.