Sprint Retrospective Template (With Action Items That Stick)
Your sprint retrospective isn't the problem. The problem is that it produces a wall of sticky notes and almost none of them turn into anything. Asana cites research putting the number bluntly: only about half of retrospective action items actually get completed. The other half get written down, nodded at, and quietly abandoned by the time the next sprint starts.
That's the gap this template is built to close. It has the usual Start / Stop / Continue columns, but it adds the one thing most retro templates skip: a success metric on every action item. A retrospective that doesn't produce measurable commitments tends to repeat the same problems sprint after sprint. Here's the template, then how to run it.
Use this for two-week Scrum sprints, monthly engineering retros, and post-launch reviews. Skip it for status meetings, and don't force it onto an incident post-mortem, which needs a timeline and root-cause structure of its own.
The template
1. Sprint snapshot
| Field | Notes |
|---|---|
| Sprint goal | What the team committed to this sprint |
| What actually happened | Shipped, slipped, and why |
| Key metrics | Velocity, incidents, deploys — the numbers that moved |
One line per field is enough. The snapshot anchors the conversation in what actually happened rather than what everyone remembers.
2. Start — what we should start doing
New habits or processes to introduce next sprint. Each row gets an owner so it doesn't float.
| Item | Owner |
|---|---|
| (e.g. Pair on the flaky billing test) | Name |
3. Stop — what we should stop doing
Things that slow the team down or aren't worth the cost. Frame them as practices, not people.
| Item | Owner |
|---|---|
| (e.g. Shipping without a deploy window) | Name |
4. Continue — what's working
The practices you don't want to lose. This column matters: retros that only list problems read as a complaint session, which is why people stop showing up.
| Item | Owner |
|---|---|
| (e.g. Weekly refactor hour) | Name |
5. Action items
This is where retros live or die. Keep it to three to five items. Each one needs a single owner, a realistic due date inside the next sprint, and a success metric — a number that tells you whether the change actually worked.
| Action item | Category | Owner | Due date | Success metric |
|---|---|---|---|---|
| Add a deploy window | Stop | Name | next sprint | Zero deploys outside the window |
| Pair on billing tests | Start | Name | 2 weeks | Flaky test rate below 2% |
| Keep refactor hour | Continue | Name | ongoing | Held every week |
A retro that produces three commitments with owners, dates, and metrics beats one that produces fifteen vague intentions.
How to run it
The five-step shape below is the standard one, adapted from the classic Agile Retrospectives structure that Atlassian and most others teach.
- Set the stage. State that the goal is improving the process, not blaming anyone. Psychological safety is the whole game — without it the feedback is fake.
- Gather data. Give everyone two minutes to jot notes silently before any discussion. You'll hear from more people and get sharper input than if you open the floor cold.
- Generate insights. Cluster the notes and look for patterns. Ask "what enabled that?" or "what blocked it?" — you want causes, not just symptoms.
- Decide on actions. Dot-vote on the three to five items that would have the biggest impact next sprint, then assign an owner, a date, and a success metric to each.
- Close. Summarize the commitments and confirm how they'll be tracked. At the next retro, start by reviewing last sprint's action items and closing or reassigning anything still open.
Why action items die (and how to stop it)
A retrospective is still a meeting, so it inherits every meeting's failure modes: bad notes, missing action items, and the loudest voice owning the room. The research on half of retro items going unfinished isn't a comment on your team's discipline — it's a comment on what happens when action items are reconstructed from memory after the fact.
That's where an AI meeting assistant changes the dynamic. If one joins the retro and transcribes it, it captures the Start / Stop / Continue items as people actually say them, deduplicates the same idea raised by five different people, and only records action items where someone explicitly took an owner and a deadline. The capture problem disappears, and the template stops being a thing someone fills in after the meeting — it fills itself during it.
The template still matters, because the assistant fills whatever structure you give it. A retro without a success-metric column is just an organized venting session, whether a human or an AI writes it down.
The point
The average sprint retrospective runs about an hour and eleven minutes, according to Scrum research cited by Asana. If you're going to spend that hour, you want it to change the next sprint, not just describe the last one. This template pairs a proven structure with a success metric on every commitment, so each action item has a name, a date, and a way to tell whether it worked.
The retrospective isn't where the value is. It's what you do with the three to five items that come out of it — and that only happens when they're written down with a name and a date attached.