Sprint retrospective template
Most retros produce good conversations and forgotten actions. This template keeps the discussion focused and ends with two or three actions that each have an owner and a date, so next sprint is actually better.
Updated
The short answer
A sprint retrospective is a short meeting at the end of each sprint where the team reviews what went well, what didn't and what to change. Use a simple format such as Start / Stop / Continue, agree no more than three actions, give each an owner and a date, and review them at the start of the next retro.
Pastes with formatting into Google Docs, Word, Notion and Confluence.
Example: fictional Meridian Labs data
Sprint 14 retrospective
Date: 25 Sep 2026 | Facilitator: Noor Haddad (rotating) | Attendees: Pulse Analytics team, Avery Nolan
Last retro's actions
| Action | Owner | Done? |
|---|---|---|
| Add a consumer-restart test to Event ingestion | Tom Reyes | Yes |
| Timebox refinement to 45 minutes | Noor Haddad | Yes |
Sprint in numbers
- Committed: 34 points | Completed: 26 points
- Carried over: 2 Streaming aggregation issues
Start
- Raising dependencies on day one, not when we're blocked
Stop
- Starting Dashboard builder stories before the schema contract is agreed
Continue
- Pairing on Event ingestion; it's at 85% with no rework
Actions (max 3)
| Action | Owner | Due |
|---|---|---|
| Chase the event schema contract at the PI sync | Avery Nolan | 1 Oct |
| Split Streaming aggregation into smaller stories | Ines Batra | 29 Sep |
New to retrospectives? Start here
What it is
A sprint retrospective is a short meeting at the end of every sprint where the team looks at how it worked, not what it built, and agrees one to three changes to try next sprint.
Use it when
- At the end of every sprint
- After a launch or incident
- When the team keeps hitting the same problem
Who writes it
A facilitator: a scrum master, engineering manager or a rotating team member
Who reads it
The whole delivery team, including the product manager
How to fill it in
- 1Last retro's actions
- Start here, every time. If actions never get done, the team stops believing retros matter.
- 2Sprint in numbers
- Two or three facts to ground the discussion, so it isn't only feelings.
- 3Start / Stop / Continue
- Give everyone five quiet minutes to write, then group similar notes before discussing.
- 4Actions
- Three at most. Each needs one owner and a date. "We should communicate better" is not an action.
Three formats to rotate
- Start / Stop / Continue: simple and direct. Good default.
- Mad / Sad / Glad: surfaces how the sprint felt. Useful after a hard sprint.
- 4Ls (Liked, Learned, Lacked, Longed for): good for longer or unusual sprints.
Rotate formats every few sprints so retros don't go stale.
Questions that get past "it was fine"
- What slowed us down that we could have seen coming?
- Which dependency surprised us, and when could we have spotted it?
- What did we carry over, and why?
- If we ran this sprint again, what one thing would we change?
Retro actions in a doc
- Written down, then never opened again
- No owner reminders
- Disconnected from the next sprint
Retro actions in Ondule
- Add each action as an issue in the next sprint, with an owner
- Dependencies that surprised you get tracked with due dates
- Decisions from the retro go in the decision log
How to do this in Ondule
Questions
- How long should a sprint retrospective be?
- About 45 minutes for a two-week sprint. Longer sprints may need up to 90 minutes.
- Who should attend a sprint retrospective?
- The whole delivery team, including the product manager or product owner. Keep outside stakeholders out so people speak freely.
- How do you make retro actions stick?
- Limit them to three, give each an owner and a date, add them to the next sprint, and review them at the start of every retro.