The purpose of the Sprint Retrospective

The Sprint Review asks whether the team built the right thing. The Retrospective asks a harder question: are we getting better at building it? Most teams find the second easier to skip, which is the best reason to look at what it is for.

What the Guide says

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led the team astray are identified, and their origins explored. The team discusses what went well, what problems it encountered, and how those problems were or were not solved.

It then identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible, and they may even be added to the Sprint Backlog for the next Sprint.

Three details are worth noticing.

• It looks at how the team worked. The list is individuals, interactions, processes, tools and the Definition of Done. The product itself is the Sprint Review's subject.
• It looks for the origin of problems. The Guide does not ask only what went wrong, but what assumptions led the team astray, and where they came from.
• It ends in changes. The output is improvements, and the best of them go into the next Sprint Backlog so that they are treated as work.

The Sprint Retrospective concludes the Sprint. It is time-boxed to a maximum of three hours for a one-month Sprint, with shorter times for shorter Sprints.

Who attends

The Scrum Team: the Developers, the Product Owner and the Scrum Master. This is not a stakeholder event. The point is a conversation among the people who did the work, and it only works if they can be candid. Adding managers or clients changes what people are willing to say.

The SBOK® Guide has a slightly different view of attendance. In its Retrospect Sprint Meeting, all Scrum Team members attend and the Scrum Master facilitates or moderates. It says the Product Owner's attendance is recommended but not required, and that one team member acts as the scribe. The Scrum Guide counts the Product Owner as part of the Scrum Team, so the difference is mostly in what is stressed. In both, the Scrum Master has a duty to keep the setting open and relaxed enough for full participation.

What the SBOK adds

The SBOK describes the primary objectives of the meeting as identifying three kinds of item: things the team needs to keep doing, which are best practices; things the team needs to begin doing, which are process improvements; and things the team needs to stop doing, which are process problems and bottlenecks. These areas are discussed and a list of agreed actionable improvements is created.

That is the familiar Start, Stop, Continue shape, and it is a good first format because it is easy to run and hard to misunderstand. The SBOK also lists other tools. ESVP (explorer, shopper, vacationer, prisoner) is an opening exercise in which attendees anonymously indicate how they feel about being there, to set the tone. Speed Boat has the team record engines that help reach the island of the project vision and anchors that hold them back, then vote on priorities. It also lists metrics, such as velocity, the share of committed story points that were done, estimation effectiveness and team morale ratings, as inputs.

The Scrum Guide does not prescribe any format. It says what the event is for and leaves the how to the team.

A basic structure

This is an illustration, not a rule, for a three-hour event on a four-week Sprint, scaled down for shorter ones.

1. Set the stage (5 to 10 minutes). Restate the purpose and the ground rules. A short check-in, where everyone says one thing, gets every voice into the room early.
2. Gather what happened (20 to 30 minutes). Collect observations on a timeline or a board, and keep to facts at this stage.
3. Make sense of it (30 to 45 minutes). Group the items, look for causes, and ask what assumptions lay behind the problems.
4. Choose changes (30 minutes). Pick one to three improvements, not ten. Make each specific enough to start on Monday.
5. Close (10 minutes). Read back the commitments and say who owns each one.

The result is a short list that goes into the next Sprint Backlog. How to keep those items alive is the subject of retrospective actions that actually happen.

Settling the practicalities

A few decisions made once save time at every retrospective.

• Who facilitates. The Scrum Master is accountable for making sure the event takes place and is positive and productive, but they may ask a Developer to run it for a change, which gives the Scrum Master a chance to take part as a member.
• Where the notes go. Whatever is recorded should be visible to the team afterwards, and the improvements should live somewhere they will be seen daily. The SBOK suggests one team member acts as scribe.
• How candid it can be. Agree at the start that what is said stays in the room unless the team decides otherwise. That agreement is what makes openness possible.
• How to handle a remote team. The purpose does not change, but silence is harder to read on a call, so a shared board where everyone writes at once helps quieter members be heard.

Common mistakes

• Treating it as a complaints session. Venting has value, but a list of grievances is not a plan.
• Always the same format. Repeating the same questions tends to produce the same answers. Change the exercise from time to time while keeping the purpose.
• Skipping it when busy. It is tempting to drop the Retrospective when a deadline looms, and a team under pressure is exactly the one that needs it.
• Blaming people. The Guide asks about processes, interactions and assumptions. A retrospective that names an individual as the problem has stopped working. The Scrum Master's job is to keep the discussion on the system.
• Too many improvements. Ten commitments mean none are done. Choose the ones that matter most.
• No follow-up. If last Sprint's improvement is not mentioned at the start of this one, people learn that the event is a ritual.

The Agile Manifesto states the idea in one line: at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

How to practise it

Running a retrospective is a facilitation skill, and the hard part is steering the team from complaint to commitment. In the simulator the retrospective follows a Start, Stop, Continue shape, and you choose which improvements the team commits to.