The Sprint Retrospective is the moment when a Scrum Team looks back on how it worked, and decides what it will do better next time. It is the last event of the Sprint, after the Sprint Review and before the next Sprint Planning. Where the Review is about what the team built, the Retrospective is about how.
What is a Sprint Retrospective?
In Scrum a team works in Sprints of at most a month. Each Sprint has four events, as shown in the image at the top of this article: Sprint Planning, the daily Daily Scrum, the Sprint Review and finally the Sprint Retrospective. According to the Scrum Guide, the purpose of the Retrospective is to plan ways to increase quality and effectiveness.
The team looks at individuals, interactions, processes, tools and its Definition of Done: the agreement on when work is truly done. The questions are simple:
- What went well?
- What went less well, or could be better?
- What will we change?
The Retrospective lasts at most three hours for a one-month Sprint, and less for shorter Sprints. For a two-week Sprint, an hour and a half is common.
Who takes part?
The whole Scrum Team: the Developers, the Product Owner and the Scrum Master. The Scrum Master makes sure the Retrospective takes place and everyone understands its purpose, and often facilitates. But the Scrum Master is also simply a member of the team, and therefore also a subject of the conversation. The Retrospective belongs to the team, not to the Scrum Master.
It has to be a safe place. Many teams start with Norm Kerth’s Prime Directive, which in short says that everyone did the best they could with what they knew at the time. It is about improving the work, not about finding someone to blame.
A Retrospective in five steps
Esther Derby and Diana Larsen described in Agile Retrospectives (2006) a five-step structure that many teams use. It is shown below.
This is one of the tools you learn to apply in the Green Belt training.
- Set the stage. State the purpose and let everyone say something at the start. Those who speak in the first minutes also join in later.
- Gather data. What happened? Collect facts: figures, notable moments, what was finished and what wasn’t.
- Generate insights. Why did it go this way? Look for patterns and causes, for example by asking “why” a few times in a row.
- Decide what to do. Choose one or two improvements, not ten. Make them concrete and give them an owner.
- Close. Sum up what the team takes away, and ask how the Retrospective itself went.
Vary the format too, so the conversation doesn’t wear thin. Well-known formats are Start, Stop, Continue (what do we start, what do we stop, what do we keep?) and the Sailboat (what gives us wind in our sails, what holds us back like an anchor, which rocks lie ahead?).
After the Retrospective
A Retrospective without follow-up is just a chat. The team picks up the most important improvements as soon as possible; they can also go on the Sprint Backlog for the next Sprint, so they don’t disappear among the other work. Start the next Retrospective by asking whether the previous improvements worked.
Improvement can of course happen any time, even mid-Sprint. But the Retrospective ensures a fixed moment in every Sprint to reflect on it deliberately. That is the same idea as Kaizen and the PDCA cycle from Lean: a little better every time.
Where it often goes wrong
- The same every time. The same questions in the same format produce the same answers after a few rounds.
- Too many action points. Ten improvements become none. Choose one or two.
- No safety. If people don’t dare say what is going on, it stays on the surface.
- Skipping it when busy. That is exactly when looking back is most needed.