How to run a sprint retrospective
By the RetroPop team · Updated
A sprint retrospective is the Scrum event where the team looks back at the last sprint and decides what to change. Run it in five steps: set the stage, gather data, generate insights, decide what to do, and close. Leave with one to three owned actions, and check them at the next retro.
What is a sprint retrospective?
It is the last event of a Scrum sprint: the Scrum Team inspects how the sprint went and identifies the most helpful changes to improve its effectiveness.
According to the Scrum Guide (2020), the team looks at how the last sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. It discusses what went well, what problems it ran into and how they were (or were not) solved. The most impactful improvements are addressed as soon as possible and may be added to the Sprint Backlog for the next sprint.
Outside Scrum, the same idea is simply called a retrospective or retro: any team can hold one at the end of a project, release or month.
Who attends a sprint retrospective?
The whole Scrum Team: the Developers, the Product Owner and the Scrum Master.
The Scrum Master usually facilitates, but anyone can, and rotating the facilitator keeps retros fresh. Stakeholders normally don't attend: the retro is a safe space for the team to talk openly about how it works. Stakeholder feedback on the product belongs in the Sprint Review.
How long should a sprint retrospective take?
The Scrum Guide sets a maximum of three hours for a one-month sprint, and usually less for shorter sprints. Most teams with two-week sprints need 45 to 90 minutes.
| Sprint length | Typical timebox |
|---|---|
| 1 week | 30–45 minutes |
| 2 weeks | 45–90 minutes |
| 3 weeks | 1–2 hours |
| 4 weeks (1 month) | Up to 3 hours (Scrum Guide maximum) |
The five steps of a retrospective
A widely used structure, from Esther Derby and Diana Larsen's book Agile Retrospectives, has five steps: set the stage, gather data, generate insights, decide what to do, and close.
- Set the stage (5 minutes). Welcome everyone, state the goal and the timebox, and remind the team that the retro is about the system, not about blaming people. A one-word check-in helps everyone speak early.
- Gather data (10–15 minutes). Everyone writes notes silently, one idea per note, using the prompts of your chosen format. Silent writing stops the loudest voices from steering the discussion.
- Generate insights (10–20 minutes). Read the notes, cluster duplicates, and vote on the themes that matter most. Discuss the top themes and ask why things happened, not only what happened.
- Decide what to do (10 minutes). Turn the top themes into one to three actions. Each needs an owner, a target date and a way to tell whether it helped.
- Close (5 minutes). Recap the actions, thank the team and ask for quick feedback on the retro itself so the next one is better.
Which retrospective format should you use?
Pick the format that fits the question the team needs to answer this sprint. Changing format every few sprints keeps retros from becoming routine.
| Format | Best for |
|---|---|
| Start, Stop, Continue | Clear behaviour changes; teams new to retros |
| What Went Well | A balanced, familiar retro for any sprint |
| 4Ls (Liked, Learned, Lacked, Longed For) | Lessons at the end of a project or release |
| Mad, Sad, Glad | Morale and how the sprint felt |
| 5 Whys | One recurring problem and its root cause |
| Timeline | Long periods or incidents people remember differently |
| Pre-mortem | Risks before a project starts |
How do you turn a retrospective into real improvements?
Agree on fewer, smaller actions, give each one an owner and a check date, and start the next retro by reviewing them.
- Limit the list to one to three actions. A long list usually means none get done.
- Write actions as experiments: “For two sprints, we will… and we'll know it worked if…”.
- Give every action one owner who coordinates it, even if the whole team takes part.
- Put the actions where the team works, for example in the Sprint Backlog.
- Review last retro's actions in the first five minutes of the next one.
How do you run a retrospective with a remote or distributed team?
Use a shared online board, keep cameras optional, use silent writing and timers, and make it easy for everyone to contribute, including people in other time zones.
- Send the link before the meeting so people can join without accounts or setup.
- Start with silent writing so quieter people and non-native speakers contribute equally.
- Use anonymous notes when the topic is sensitive.
- Use visible timers for each step, and vote instead of debating who speaks first.
- If time zones make a live meeting hard, let people add notes beforehand and keep the live part to discussion and actions.
Common sprint retrospective mistakes
The most common problems are retros with no actions, the same complaints every sprint, blame, and a few people doing all the talking.
- No follow-through: actions are agreed but never checked.
- Too many topics: the team discusses everything and decides nothing. Vote first.
- Blame: discussing people instead of the process makes the team stop talking openly.
- Same format forever: the answers become predictable. Rotate formats.
- Skipping the retro when the sprint went well: good sprints have lessons too.
Running your sprint retrospective in RetroPop
RetroPop is an online retrospective tool that walks the team through these steps with guided stages, silent writing, voting, timers and action items with owners.
Pick a format, share the link, and teammates join with just their name. The facilitator moves the team from stage to stage; everyone sees the same board live. At the end you get a summary with the agreed actions. It's free for up to 10 boards.
Templates to try
Run your next retro in RetroPop
Guided stages, silent writing, voting, timers and action items. Free for up to 10 boards.
Start a retro — it's free