Goal of a retrospective
The goal is to learn what worked, what did not, and what to change — then commit to specific experiments with owners.
Before the meeting
- Frame it as improvement, not blame
- Collect any data or metrics in advance
- Keep it to the team that did the work
Retrospective agenda (90 minutes)
- 0:00–0:10
Welcome and safety
Frame the goal and ground rules.
- 0:10–0:25
Silent reflection
Individual start/stop/continue notes.
- 0:25–0:45
Sharing and clustering
Group themes on a shared board.
- 0:45–1:10
Root-cause discussion
Dig into the top two or three themes.
- 1:10–1:25
Experiment selection
Pick 1–3 small experiments to try.
- 1:25–1:30
Owners and follow-up
Assign owners and set the next check-in.
Common mistakes
- Blame replacing learning
- The same issues repeating with no action
- Experiments with no owners
- No follow-up date
After the meeting
Record the experiments, owners and the next check-in. At the next retrospective, start by reviewing whether the experiments worked.
Why this structure works
The agenda follows the five-stage retrospective structure described by Esther Derby and Diana Larsen in Agile Retrospectives: set the stage, gather data, generate insights, decide what to do, and close. Each stage has a job. Skip gathering data and the discussion runs on impressions. Skip generating insights and you fix symptoms. Skip deciding and nothing changes.
Many teams open with Norm Kerth’s Prime Directive, the statement that everyone did the best job they could given what they knew at the time. Reading it aloud is not a ritual for its own sake. It sets the expectation that the meeting is about the system and the process, not about who is to blame.
Facilitator prompts for each block
- Welcome: “On a scale of 1 to 5, how openly can you talk about this sprint today?” If scores are low, address that before anything else.
- Silent reflection: “Write one note per idea. What should we start doing, stop doing, and keep doing?” Give a hard five to ten minutes of silence.
- Clustering: “Which of these notes are really about the same thing?” Let the team group them and name each cluster.
- Root cause: “Why did this happen?” Ask it up to five times for the top themes, and stop when the answer is something the team can change.
- Experiments: “What is the smallest change we could try for the next two weeks, and how will we know if it helped?”
- Close: “Who owns this experiment, and when do we check it?”
Retrospective formats to rotate
Running the same format every sprint makes retros predictable and shallow. The agenda above stays the same; only the reflection prompt changes. Start, Stop, Continue is the default. Mad, Sad, Glad surfaces emotional friction a process-focused format misses. The 4Ls (liked, learned, lacked, longed for) works well after a release or a long project. The Sailboat (wind, anchors, rocks, island) helps a team talk about risks and goals, not only the past sprint. A timeline retro, where the team plots events and mood over the period, suits longer projects where people have forgotten the early weeks.
Shorter version: a 45-minute sprint retro
For a two-week sprint, 45 minutes is usually enough: check-in and review of last experiments (5 minutes), silent reflection (8), sharing and clustering (10), discussion of the top theme only (12), one experiment with an owner (7), close (3). Focusing on one theme is the key trade-off. It is better to fix one thing properly than to list five and change none.
Running a retrospective remotely
- Use a shared board where everyone writes at the same time, and keep notes anonymous during reflection if trust is fragile
- Ask for cameras on during discussion but not during silent writing
- Use dot-voting on the board to pick themes rather than asking who wants to talk about what
- Keep the experiment list in the team’s normal tracker, not in the retro board, so it gets seen between meetings
Key takeaway
A retrospective earns its place only if it ends with a few real experiments and owners who will run them.
Frequently asked questions
How long should a retrospective be?+
The Scrum Guide caps the sprint retrospective at three hours for a one-month sprint, which works out to roughly 45 minutes per week, or about 90 minutes for a two-week sprint. Many teams manage a focused sprint retro in 45 to 60 minutes by discussing only the top one or two themes. Project or release retrospectives often take half a day.
Who should attend a retrospective?+
The team that did the work. Managers and stakeholders usually stay out unless the team invites them, because their presence can make people less candid about problems.
Who facilitates a retrospective?+
Often a Scrum Master or team lead, but rotating the role among team members works well. For a retro about a conflict or a failed project, a facilitator from outside the team helps keep it neutral.
What if the same problems come up every retrospective?+
That usually means actions are too big, have no owner, or are never reviewed. Pick one small experiment, give it an owner and a check date, and open the next retro by reviewing whether it worked.
What is the difference between a retrospective and a post-mortem?+
A retrospective is a regular, forward-looking review of how the team works. A post-mortem usually follows a specific incident or failed project and focuses on what happened and how to prevent it. Both work best when they are blameless.