sprint retrospective template
A retro that does not produce exactly three action items with owners and due dates is a therapy session, not a process improvement tool.
Most retros fail for the same reason: they become complaint sessions. The team vents for 45 minutes, someone writes “improve communication” on a sticky note, and nothing changes. Two weeks later, the same problems show up. The team stops believing retros work. They become a calendar ritual everyone tolerates.
The fix is structural, not cultural. You do not need a better facilitator or fancier sticky notes. You need a format that forces specificity, limits scope, and tracks follow-through. This template does that. It caps action items at three, requires owners and due dates for each, and opens every retro by reviewing whether last sprint’s action items actually happened.
I have watched this format work across 200+ teams — from 4-person startups to 50-person platform squads. The teams that run it consistently improve. The ones that skip the follow-up section do not.
The template
Copy everything between the horizontal rules below.
# Sprint Retrospective
**Sprint:** [Sprint number or name]
**Date:** [YYYY-MM-DD]
**Facilitator:** [Name — rotate this every sprint]
**Attendees:** [List everyone present]
**Duration:** 45 minutes
---
## Follow-up from last retro
[Review EVERY action item from the previous retro. Did it happen? Be honest.]
| Action item | Owner | Status |
|-------------|-------|--------|
| [Action from last sprint] | [Name] | Done / Not done / In progress |
| [Action from last sprint] | [Name] | Done / Not done / In progress |
| [Action from last sprint] | [Name] | Done / Not done / In progress |
**If not done — why not?** [One sentence. No blame. Just the reason.]
---
## What went well
[Max 3 items. Be specific — name the person, the practice, or the decision.]
1. [Specific win — e.g., "Priya caught the auth bug in code review before it hit staging"]
2. [Specific win — e.g., "We shipped the checkout flow two days early because scope was clear"]
3. [Specific win — e.g., "Daily standups stayed under 10 minutes all sprint"]
---
## What did not go well
[Max 3 items. Describe the problem, not the person. Facts, not feelings.]
1. [Specific problem — e.g., "The payments API spec changed mid-sprint with no heads-up"]
2. [Specific problem — e.g., "QA started three days late because staging was broken"]
3. [Specific problem — e.g., "We had four unplanned meetings that weren't on the sprint calendar"]
---
## What surprised us
[Unexpected learnings — positive or negative. Things the team did not anticipate.]
1. [e.g., "The new caching layer reduced load times by 40% — we expected 15%"]
2. [e.g., "Three users reported the same onboarding bug we thought was fixed in Sprint 12"]
3. [e.g., "The design handoff went smoother than any sprint this quarter"]
---
## Action items
[MAXIMUM 3. Each must have an owner and a due date. If you cannot name the owner, it is not an action item — it is a wish.]
| # | Action | Owner | Due date | Status |
|---|--------|-------|----------|--------|
| 1 | [Specific, measurable action — e.g., "Add staging health check to CI pipeline"] | [Name] | [Date] | Open |
| 2 | [Specific, measurable action — e.g., "Block 30 min before sprint start for spec review"] | [Name] | [Date] | Open |
| 3 | [Specific, measurable action — e.g., "Create shared Slack channel for API change alerts"] | [Name] | [Date] | Open |
---
## The one thing
[Each person states one behaviour they will personally change next sprint.]
- **[Name]:** [e.g., "I will flag scope changes within 2 hours instead of waiting for standup"]
- **[Name]:** [e.g., "I will write test cases before starting implementation"]
- **[Name]:** [e.g., "I will push back on unplanned meetings that don't have an agenda"]Facilitation notes
Timebox: 45 minutes, no exceptions. A retro that runs over an hour produces worse outcomes than one that ends at 45 minutes. Parkinson’s law applies — discussion expands to fill the time. Set a timer.
The rule of 3. Maximum three items per section. This forces the team to prioritise. If someone raises a fourth item, ask: “Is this more important than the three we have? If yes, which one does it replace?” This single constraint eliminates the retro-as-grievance-dump problem.
Start with follow-up. Always open by reviewing last sprint’s action items. This is the accountability mechanism. When teams see that action items are tracked and reviewed, they take them seriously. When follow-up is skipped, the team learns that retro action items are performative.
The “one thing” close. In the last five minutes, each person commits to one personal behaviour change. Not a team action item — a personal one. “I will flag blockers within two hours instead of sitting on them.” This is small enough to actually happen and personal enough to create ownership.
Rotate the facilitator. The PM should not always run the retro. Rotating forces different perspectives on what gets discussed and prevents the retro from becoming a PM status check.
Before the retro:
- Copy the template into your team’s wiki or shared doc.
- Pre-fill the “Follow-up from last retro” section with last sprint’s action items. Do this before the meeting starts — do not waste meeting time looking them up.
- Send the template link to the team 30 minutes before the retro so people can think about their items in advance.
During the retro:
- Spend the first 5 minutes on follow-up. Read each action item aloud. Mark it done or not done. Do not re-discuss — just status.
- Spend 10 minutes each on “went well,” “did not go well,” and “surprises.” Enforce the rule of 3.
- Spend 10 minutes on action items. For each problem raised, ask: “What is the one thing we can change to prevent this?” That answer becomes the action item. Assign an owner before moving on.
- Close with the “one thing” round. Each person speaks once. No discussion.
After the retro, check: did you end up with more than 3 action items? If yes, cut until you have 3. Three actions done are worth more than seven actions forgotten.
Related pages
- Sprint Planning — the other half of the sprint loop: how to plan the work that this retro will evaluate
- Agile for PMs — where retros fit in the broader agile cadence, and which ceremonies actually matter
- Running Meetings — facilitation techniques that apply to retros and every other meeting you run