A sprint retrospective is the meeting at the end of a sprint where a team looks at how it worked, not what it built, and picks something to change. Run well, it stops a team hitting the same problems every sprint. Run badly, it is an hour of sticky notes that changes nothing.
Where the retrospective fits
In Scrum, work happens in sprints: fixed blocks of time, usually one to four weeks, each with a goal. Every sprint ends with two meetings, and they are easy to mix up.
- The sprint review looks at the product. The team shows what it built and talks with stakeholders about what to build next.
- The sprint retrospective looks at the team. It comes last and closes the sprint. The question is how the team worked: its communication, its tools, its planning and its definition of 'done'.
The Scrum Guide caps the retrospective at three hours for a one-month sprint, and less for shorter ones. On two-week sprints, an hour is common. It is for the team itself: the developers, the Scrum Master and the product owner. Many teams keep managers out unless they are invited, because people speak less openly in front of the person who writes their performance review.
If Scrum and sprints are new to you, Development Methodologies compares Scrum with the other common ways teams organise their work.
The three questions
Most retrospectives come down to three questions:
- What went well? This is worth keeping, so it doesn't get dropped by accident.
- What didn't go well? Problems, blockers, surprises and frustrations.
- What will we change next sprint? These are the action items.
The classic way to run this is a board with three columns, often called 'Went well', 'Didn't go well' and 'Action items'. Everyone writes notes for the first two columns, the team groups similar notes, and the third column is filled in together at the end.
The first two columns are only input. The third column is the reason the meeting exists. A retrospective that fills the first two columns and rushes the third is a venting session.
How a good retrospective runs
A common structure, from Esther Derby and Diana Larsen's book Agile Retrospectives, has five steps:
- Set the stage: remind everyone of the goal and make it safe to be honest. Many teams read Norm Kerth's Prime Directive aloud: everyone did the best job they could with what they knew at the time.
- Gather data: collect facts before opinions, such as what was planned, what was finished, what got blocked and for how long.
- Generate insights: ask why things happened. Group the notes and look for the cause underneath the symptom.
- Decide what to do: pick one or two changes, each with an owner.
- Close: recap the action items and agree when they will be checked.
The order matters. Teams that jump straight to 'what should we fix?' tend to fix whatever was loudest, not what caused the most trouble.
A worked example
A team of five runs two-week sprints. At planning they commit to 30 tickets. By the end, 18 are done, 7 are still in progress and 5 were never started. Here is their board after grouping:
| Went well | Didn't go well | Action items |
|---|---|---|
| Pairing on the payments bug | 'Communication could be better' | Plan no more than our recent average |
| New CI pipeline is faster | Too many meetings | Cancel the Wednesday sync for a trial sprint |
| Quick code reviews | Waited 4 days on the design team | Agree a 1-day turnaround with design |
Look at how the vague notes became specific ones. 'Communication could be better' could be said of almost any team, so the facilitator asked for an example. It turned out two people had built the same API endpoint, because nobody said what they were picking up at stand-up. That is a concrete problem with a concrete fix.
The overcommitment had a cause too. The team had finished 17, 19 and 18 tickets in its last three sprints, then planned for 30 because the backlog was long and the deadline was close. The fix is to plan from what the team has finished before, not from what it hopes to finish.
Each action item gets an owner and goes into the next sprint's backlog, where everyone can see it. At the start of the next retrospective, the team checks each one: done, not done, and did it help?
Turning complaints into action items
A good action item is:
- Specific: 'Improve communication' is a wish. 'Say which ticket you are starting at stand-up' is an action.
- Small: it fits inside one sprint alongside the planned work.
- Owned: one named person makes sure it happens. 'The team' owns nothing.
- Checkable: at the next retrospective, everyone can say whether it was done.
One or two of these beat a list of ten. A team that agrees to ten changes usually makes none of them, because nobody can hold ten new habits while also shipping features.
Common mistakes
- Vague feedback: 'Communication could be better' and 'the sprint was fine' leave nothing to act on. Ask for one example.
- Blame: 'The product team keeps changing things' points at people outside the room, and the team stops looking at its own part. Ask what the team can change: shorter feedback loops, an earlier check-in, a clear cut-off for scope changes.
- Saying it was fine when it wasn't: when people feel unsafe, they say nothing. If every retrospective is quiet, the problem is trust, and the facilitator has to fix that first.
- Solving every problem with another meeting: if the complaint is too many meetings, the answer is rarely a follow-up meeting.
- Never reading the action items again: the same problems come back sprint after sprint on new sticky notes, and people decide retrospectives are pointless. Checking last sprint's actions first stops this.
- The same format every time: the same three columns every sprint get the same answers. Changing the format now and then helps, such as 'Start, Stop, Continue' or 'Mad, Sad, Glad'.
Key takeaways
- A sprint retrospective closes the sprint and looks at how the team worked, not what it built.
- It asks what went well, what didn't, and what to change next sprint.
- Turn vague complaints into specific, small, owned action items, and pick only one or two.
- Put action items in the next sprint's backlog and check them at the start of the next retrospective.
- If the same problems keep coming back, the action items are not being followed up.
