Originally published on AIYUN.
To run a sprint retrospective, block 45–90 minutes at the end of the sprint and invite only the team. Open with the reason for the meeting, gather what actually happened, dig into why, agree one to three concrete actions with owners, and close with a quick check on whether the time was well spent. The rest of this guide is the detail: what to prepare, a minute-by-minute agenda, and what to do when the conversation goes wrong.
If you only want new formats to try, see 25 retrospective ideas and formats. This page is about running the meeting itself.
What a sprint retrospective is for
A sprint retrospective is the team's regular meeting to look at how they worked, not what they built, and decide what to change in the next sprint. The 2020 Scrum Guide places it at the end of the sprint and timeboxes it at up to three hours for a one-month sprint, and shorter for shorter sprints. For a two-week sprint, 60 minutes is usually enough.
The output is not a list of complaints. It is a small number of changes the team will actually try.
Before the meeting (15 minutes of preparation)
- Check last retro's actions. Did they happen? You will open with this.
- Pull a few facts. Sprint goal met or not, what was finished, incidents, unplanned work. Facts keep the discussion away from impressions.
- Pick a format that fits this sprint. A hard sprint calls for something different from a quiet one.
- Set up the board before anyone joins, with columns, a timer and a place for actions.
- Decide who attends. The team, including the Product Owner and Scrum Master. Managers outside the team usually make people more careful about what they say.
A 60-minute sprint retrospective agenda
This agenda follows the five stages from Esther Derby and Diana Larsen's book Agile Retrospectives (2006). Most retro formats only change the middle three stages.
| Time | Stage | What happens |
|---|---|---|
| 0–5 min | Set the stage | Purpose, a one-word check-in, last retro's actions |
| 5–20 min | Gather data | Everyone writes cards silently, then reads them out |
| 20–40 min | Generate insights | Group cards, dot vote, discuss the top two or three |
| 40–55 min | Decide what to do | One to three actions, each with an owner and a date |
| 55–60 min | Close | Quick rating of the retro, thanks |
1. Set the stage (5 minutes)
Say why you are here and how long it will take. Many teams read Norm Kerth's Prime Directive: whatever we discover, we believe everyone did the best job they could with what they knew at the time. Then ask each person for one word about the sprint. Everyone speaks once in the first five minutes, which makes them much more likely to speak later.
Finish by reviewing last retro's actions: done, not done, or dropped. Skipping this step is the main reason teams stop believing retros change anything.
2. Gather data (15 minutes)
Give everyone five to seven minutes to write cards silently, one idea per card. Silent writing matters: it stops the first or loudest speaker setting the direction. With prompts like "Went well / Didn't go well / Puzzles us", people then read out their cards briefly, without debate yet.
3. Generate insights (20 minutes)
Group similar cards, give each person three votes, and sort by votes. Discuss the top two or three themes and ask "why" until you reach something the team can influence. Asking "What would have to be true for this not to happen again?" moves a discussion from blame to causes.
4. Decide what to do (15 minutes)
Agree at most three actions. Each one needs an owner, a date and a way to know it worked. "Improve communication" is not an action. "Post blockers in the team channel before 10am stand-up, owner Sam, review next retro" is. If an action needs work, add it to the next sprint backlog so it competes for time like everything else.
5. Close (5 minutes)
Ask everyone to rate the retro from one to five, or say one thing to keep or change about the meeting itself. This takes a minute and tells you when the format has gone stale.
Running a retrospective remotely
- Cameras on for the opening if people are comfortable, then whatever works.
- Use a shared board that people can join from a link without making an account, so nobody loses the first ten minutes to sign-up.
- Hide cards while people write so ideas don't anchor on each other, then reveal them together.
- Use a visible timer for each stage; remote meetings drift faster.
- Call on people by name, gently, in a fixed order for check-ins, so quieter teammates aren't left out.
RetroLift does all of this in the browser: hidden cards, voting, a timer, action items carried into the next retro, and themed templates when the usual format gets dull. It is free and made by AIYUN, and teammates join from a link or QR code.
Common problems and fixes
| Problem | Fix |
|---|---|
| Same issues every retro | Check whether past actions were done. If they weren't, the real issue is follow-through, so make that the topic. |
| One person dominates | Silent writing first, round-robin read-outs, and a timer per speaker if needed. |
| Nobody says anything negative | Make cards anonymous, ask about the process rather than people, and leave the manager out. |
| Too many actions, none done | Cap at three, give each an owner, and put them on the sprint board. |
| It feels like a ritual | Change the format, change the facilitator, or try a Lean Coffee retro where the team sets the topics. |
| Low energy at the start | Open with a short icebreaker, or a quick team health check to give the discussion a focus. |
Frequently asked questions
How long should a sprint retrospective be?
The Scrum Guide sets a maximum of three hours for a one-month sprint and less for shorter sprints. In practice, 45 to 60 minutes works for a two-week sprint and 90 minutes for a month. If you regularly run out of time, cut the number of topics you discuss rather than rushing the actions.
Who should facilitate a sprint retrospective?
Often the Scrum Master, but anyone on the team can. Rotating the facilitator every few sprints brings new formats and lets the Scrum Master take part as a team member. The facilitator keeps time and makes sure everyone is heard; they don't decide the actions.
What is the difference between a sprint review and a sprint retrospective?
The sprint review looks at the product: what was built, shown to stakeholders, with feedback on what to do next. The retrospective looks at the team's way of working and is usually just for the team. The review comes first, then the retrospective closes the sprint.
What should come out of a sprint retrospective?
One to three specific improvement actions, each with an owner and a date, that the team will try in the next sprint. A good retro also leaves people feeling heard, but the actions are what make the next sprint different.
Disclosure: I build RetroLift and the other free Lift Apps tools mentioned here.
Top comments (0)