The least understood Scrum ritual is the retrospective. Plenty of teams fill in the “What went well / What didn’t / What to improve” template, leave 30 minutes later, and watch the same issues come back 6 months on. For a retrospective to deliver real value, it has to shift from form-filling to problem-solving.
Over the last 5 years I’ve facilitated retros across a range of teams. Here’s what works and what doesn’t.
Clarify the purpose
A retrospective should not be:
- A planning meeting (don’t drag next sprint’s work in here)
- A standup (daily coordination is separate)
- A demo (work showcase is separate)
- Finger-pointing (this isn’t to blame someone)
The single goal of a retrospective is to improve how the team works. Which process, tool, or communication pattern isn’t working, which one is, and who’s going to do what to change it.
Start with data, not feelings
“How did the sprint go?” collects feelings, not data. Feelings matter but they’re not enough.
Prep these numbers before the meeting:
- Sprint velocity (planned vs completed story points)
- Bugs that leaked to production
- Unplanned work ratio (mid-sprint additions)
- Code review turnaround time
- Deploy frequency
- Estimation accuracy, calibrated
Present those metrics for 5 minutes at the start and the discussion gets much more concrete.
Rotate the format
Run the same format long enough and brains go on autopilot. Formats I’ve tried and kept:
Start / Stop / Continue. Classic but effective. What should we start, what should we stop, what should we keep doing.
4 L’s (Liked / Learned / Lacked / Longed for). Adds learning to the agenda. What was liked, learned, lacking, longed for.
Sailboat. Which winds pushed our boat forward, which anchor slowed us, which rock is the danger, which island is the goal. Works well on creative teams.
Mad / Sad / Glad. Separates emotional states. On teams with friction, it opens space to talk about the feeling itself.
Timeline retro. Write the sprint out as a sequence of events and stick red/green notes on each. Great for long sprints or project checkpoints.
5 Whys. Focus on one problem and drill to root cause. “Why did the bug ship?” five levels deep.
Rotation keeps the team fresh. The same structure week after week drains creative energy.
Facilitation: everyone speaks
The quietest person in the retro often has the most critical insight. The facilitator’s job is to pull input from everyone.
Techniques:
Silent writing. The first 5 minutes nobody talks, everyone writes their own items. Then share. The loudest voice doesn’t steamroll the most thoughtful one.
Round-robin. On every item, everyone comments in turn. Dominant personalities can’t monopolise.
Dot voting. Everyone gets three votes, and we focus on the top 2 or 3 items. Time budget spent well.
Seniority order. Juniors go first, managers last. Flattens hierarchy influence.
The most important step: action items
The failure mode of a retrospective: lots of talk, zero change. A retro without action items is empty calories.
Action items have to meet these criteria:
- An owner: a name is attached
- A due date: next sprint or sooner
- Specific: not “improve communication”, but “cameras on for every standup”
- Measurable: done or not done, unambiguous
Keep the list under three. With 10 action items, none ship. With three, two do.
Review last retro’s action items
Every retro starts by reviewing last time’s action items:
- Done?
- If not, why?
- Did it move the needle?
Without this discipline, action-item culture collapses. The team assumes “nothing ever gets done” and the retro loses weight.
Psychological safety
Retrospective quality is directly proportional to psychological safety. Can team members say they made a mistake, need help, have a problem with the process?
On teams where a manager or senior goes defensive on feedback, the retro dies fast. One person takes a shot, defensiveness shows up, and nobody speaks openly again.
The facilitator’s role here is critical. When defensiveness shows up, push the conversation forward with “let’s make this feedback concrete, what would actually change”. Pull the defender out of defence.
Extreme cases
If the team is toxic and the retro is impossible to facilitate, bring someone in from outside. An agile coach or neutral facilitator can break a bad pattern over a two-hour retro.
Retrospective cadence
Biweekly at the end of a sprint is standard. I’ve also run monthly retros on top of sprint-level ones for strategic issues. Project-end retros (kickoff-to-close) are worth doing for large projects to extract lessons.
Teams with a working retrospective outperform teams with better everything else. If you want to measure team health, look at what happens in the retro.