Sprint Retrospective Template (Free)
Sprint retrospectives are the single most valuable meeting in an agile process — and the most commonly done wrong. The format matters less than the outcome: every retrospective should end with 2–3 specific, owned action items that the team commits to doing in the next sprint. Without that, retros become a venting session that changes nothing.
This free template gives you a consistent structure that keeps retros focused and under 45 minutes. It works for 2-week sprints, 1-week sprints, and any team size from 3 to 15. The questions are designed to surface process improvements, not assign blame — because the goal is a better next sprint, not a record of what went wrong.
What separates great retros from useless ones
Most retro failures share a common cause: too many items, no owners, no follow-up. Teams generate ten improvement ideas, commit to none of them specifically, and then open next sprint's retro by tackling the same problems. The fix is ruthless limitation: pick the top two or three improvements and turn each into a single action item with a specific owner and due date.
The quality of discussion also depends heavily on psychological safety. Teams that have built trust will surface real problems; teams that haven't will only mention safe ones. If your retros feel surface-level, the template is not the problem — the team culture is. One tactical fix: collect observations anonymously before the meeting (tools like FunRetro or even a shared doc), then discuss in the meeting. Anonymous input surfaces issues that people would not raise publicly.
Finally, retros should be forward-looking, not backward-looking. The goal is not to document what went wrong — it is to improve the next sprint. Frame every item on the "what to improve" list as a proposed change: not "code reviews took too long" but "we will add a 24-hour SLA to PR reviews, with an escalation path if it is not met."
Template sections
5 sections covering the complete sprint planning workflow.
Sprint summary (5 minutes)
Start with facts, not feelings. Report planned vs. completed points or story count, whether the sprint goal was achieved (yes/partial/no), and what carry-over items exist. This grounds the discussion in data before moving to retrospective questions.
Sprint 23 Summary: - Planned: 34 points | Completed: 28 points (82%) - Sprint goal: Partially achieved (payment flow shipped; email notifications carried over) - Carry-over: T-47 (Email notifications), T-52 (Retry logic)
Tips
- Do not spend more than 5 minutes on this section — it is context, not discussion
- If the sprint goal was partially missed, note which part was missed and why it was not flagged earlier — this prevents the same pattern from repeating
- Velocity data is most useful when tracked across 3–5 sprints to identify trends
What went well
Ask: what practices, decisions, or team behaviors contributed to the good outcomes this sprint? Be specific — "good communication" is useless; "we caught the auth regression in peer review before it hit QA" is actionable because it names what to repeat.
1. Pairing on the payment integration caught 3 edge cases before QA — consider pairing for all P0 stories going forward. 2. Daily async updates in Slack meant no one was blocked for more than a few hours. 3. The engineering brief before sprint start meant no mid-sprint architecture surprises.
Tips
- Push for specificity: ask "what specifically went well?" if someone gives a general answer
- Write these up — if you do not record what worked, you cannot systematically repeat it
- Limit to the top 3–5 items. Do not pad this section — only list things worth reinforcing
What to improve
Ask: what slowed us down, caused rework, or created friction that we could reduce? Frame everything as a process question — "the estimation process underestimated the payment work" not "John underestimated." Focus on systemic causes, not individual performance.
1. Two stories were blocked on design decisions mid-sprint that should have been resolved in refinement. → Add a design sign-off checklist to the Definition of Ready. 2. PR review cycle averaged 3 days, creating bottlenecks. → Set a 24-hour review SLA with a fallback reviewer named per story.
Tips
- For each problem, ask "why did this happen?" once — the answer usually reveals whether the fix is process, tooling, or estimation
- Do not list more than five items. Every item you list without an action plan is noise
- If the same item appears in multiple retros, it is a systemic problem that needs a dedicated working session, not a retro action item
Action items
Convert the top 2–3 improvements into specific actions with clear owners and due dates. An action item without an owner is a wish. An action item without a due date is a postponement. Both are guarantees the item will appear in next sprint's retro.
- [ ] Add design sign-off checklist to the Definition of Ready — Owner: Sarah (PM) — Due: Before Sprint 24 planning - [ ] Set 24-hour PR review SLA and add fallback reviewers to the sprint board — Owner: Marcus (EM) — Due: Day 1 of Sprint 24
Tips
- Limit to 3 action items maximum. Three completed > ten ignored
- Start the next retro by reviewing the action items from this one — this creates accountability and shows the process works
- If an action item from a previous sprint is not complete, treat it as a bug: find out why and fix the process that caused the miss
Retrospective format variations
The Start / Stop / Continue format is a useful alternative when your team is stuck on the same three topics. Sailboat retros (wind = helps, anchors = slows) work well for teams that find standard formats too serious. Rotate formats every 3–4 sprints to prevent retros from becoming rote.
Tips
- For remote teams, use digital boards (Miro, FunRetro, EasyRetro) with anonymous card submission before the meeting
- For teams with low psychological safety, have team members write cards individually before reading them aloud — this prevents anchoring on the first speaker
- A rotating facilitator keeps retros fresh and builds facilitation skills across the team
Copy-paste template
# Sprint [N] Retrospective Date: [Date] | Facilitator: [Name] | Attendees: [Names] --- ## Sprint Summary - **Planned:** [X] points / [Y] stories - **Completed:** [X] points / [Y] stories ([%] of plan) - **Sprint goal:** [Achieved / Partially achieved / Missed] - If partial/missed: [What was the specific miss and earliest signal we had?] - **Carry-over:** [List items] --- ## What Went Well *(Practices and decisions worth reinforcing — be specific)* 1. [Specific positive with context — what happened and why it worked] 2. [Specific positive] 3. [Specific positive] --- ## What to Improve *(Frame as process changes, not individual feedback)* 1. [Problem] → [Proposed fix] 2. [Problem] → [Proposed fix] 3. [Problem] → [Proposed fix] --- ## Action Items *(Maximum 3. Each must have an owner and a due date.)* - [ ] [Specific action] — Owner: [Name] — Due: [Date] - [ ] [Specific action] — Owner: [Name] — Due: [Date] --- ## Review from Last Retro *(Did we complete our previous action items?)* - [ ] [Last retro action item] — [Complete / In progress / Missed — why?]
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.