What belongs in a retrospective
A retrospective template has to do something most retro boards skip: connect this sprint's actions to the last sprint's. Every section in the template above exists to make that connection.
- Last retro's actions. Done or not, and did it work. This is the section that makes retros cumulative instead of repetitive.
- Sprint facts. Committed versus done, carry-overs, incidents. Facts keep the discussion honest.
- The format columns. Went well and did not go well, or the columns of whichever format you choose. Specific examples, not general moods.
- Still puzzling us. Questions nobody can answer yet. They often turn into next sprint's actions once someone looks.
- Top themes after voting. Everyone gets three votes. The two themes with the most votes get discussed; the rest get parked.
- Two actions, each with an owner, a date and a signal. The signal is what you check next time.
The top retrospective pages list dozens of formats. Four cover almost every situation:
- Start Stop Continue. The default. Good when the team knows what is wrong and needs to agree on what to change.
- 4Ls (Liked, Learned, Lacked, Longed for). Good for new or merged teams, because Learned surfaces the things people assumed everyone knew.
- Sailboat. Good before a deadline. It adds risks ahead, so the retro looks forward as well as back.
- Mad Sad Glad. Good after a hard sprint or an incident, when feelings are the real agenda and a process-only retro would skip them.
Change the format every few sprints if energy drops. Do not change the frame around it.
Running it in an hour
- Check last retro's actions (5 min). Read each one aloud with its signal.
- Read the sprint facts (5 min). The facilitator prepares them before the meeting.
- Silent writing (10 min). Everyone adds items under the format headings at once.
- Group and vote (10 min). Merge duplicates, three votes each.
- Discuss the top two themes (20 min). Ask why until you reach something the team can change.
- Write the actions (10 min). Owner, date, and how you will know.
Following up between retros
This is the gap in most retrospective guides. They say to check actions at the next retro, but not how, or what to do when an action is not done.
Put each action into the sprint where people actually look: the board, the tasks list, the daily note. A retro action that only lives in the retro note will be read again in two weeks, which is too late. At the next retro, check the signal you wrote, not people's impressions.
Then apply one rule to anything not done: an action carried twice either becomes planned work with an estimate, or the team drops it out loud. A third carry-over teaches everyone that retro actions are wishes. The last example above shows a team making that call after four.
Common mistakes
- Skipping the action review. The fastest way to make retros pointless.
- Seven actions. None of them happen. Two is plenty.
- Actions owned by "the team". One name per action.
- Inviting the manager by default. People edit what they say. Share the actions afterwards instead.
- Only talking about process. If the sprint had an incident or a conflict, that is the topic. Use Mad Sad Glad and let people say it.
When to use a different template
A sprint retro looks at two weeks of one team's work. For the end of a whole project, with budget, timeline and lessons for future projects, use the lessons learned template. For a single incident with a timeline and root cause, use the post-mortem template. For the daily coordination that feeds the sprint facts, the standup meeting template records blockers and how long they were open.
Retro actions that are still visible next sprint
Save this retrospective template in Scribelet, turn each action into a task with a date, and link recurring problems so you can see how many retros they have survived. Encrypted, free to start.
Free plan, no credit card. See pricing