Sprint Retrospective Template
A structured sprint retrospective template for product and engineering teams. Covers what went well, what to improve, and concrete action items — in under 60 minutes. Free to copy, download, and use. No signup required.
# Sprint Retrospective Template **Sprint:** [Sprint Number / Name] **Date:** [Date] **Facilitator:** [Name] **Team:** [Team Name] **Duration:** 60 minutes --- ## Pre-Retro Data Pull (5 min) Before the meeting, collect: | Metric | Target | Actual | Delta | |---|---|---|---| | Story points committed | | | | | Story points completed | | | | | Bugs opened | | | | | Bugs closed | | | | | Sprint goal achieved? | Yes/No | | | --- ## Format: Start / Stop / Continue ### What Went Well — Continue ✅ > Things the team did that created value. Be specific — name the practice, not just the feeling. | Item | Owner | Action | |---|---|---| | | | | | | | | ### What Needs to Change — Stop / Improve ⚠️ > Friction points, repeated mistakes, or processes that cost more than they deliver. | Item | Root Cause | Proposed Fix | |---|---|---| | | | | | | | | ### What to Try — Start 🚀 > New experiments to run in the next sprint. Each must be specific enough to evaluate. | Experiment | Owner | How We'll Measure It | |---|---|---| | | | | | | | | --- ## Action Items | # | Action | Owner | Due Date | Done? | |---|---|---|---|---| | 1 | | | | | | 2 | | | | | | 3 | | | | | **Rule:** No more than 3 action items per retro. More than 3 means none of them get done. --- ## Sprint Goal Review **What was the sprint goal?** > [State it verbatim from the sprint planning doc] **Was it achieved?** - [ ] Yes — fully - [ ] Partially — [explain what was left and why] - [ ] No — [explain root cause] --- ## Team Health Check (optional, anonymous) Rate 1–5 on each dimension. Collect via anonymous poll (Mentimeter, Slido, or sticky notes). | Dimension | Score | Trend vs Last Sprint | |---|---|---| | Clarity of priorities | /5 | ↑ / → / ↓ | | Quality of collaboration | /5 | | | Technical confidence | /5 | | | Process friction | /5 | | | Morale / energy | /5 | | --- ## Retro Review from Last Sprint **What actions did we commit to last retro?** | Action | Did we do it? | Impact | |---|---|---| | | Yes / No | | | | Yes / No | | --- ## Notes [Free-form notes, themes, or patterns observed across multiple sprints] --- *Next retro: [Date]*
How to use this Sprint Retrospective template
Pull sprint data before the meeting
Fill in the metrics table (points committed vs completed, bugs, sprint goal) before the session starts. Grounding the retro in numbers prevents the conversation from becoming purely emotional.
Run the Start / Stop / Continue exercise
Give each team member 5 minutes to add items silently (sticky notes or a shared doc). Then group, dot-vote on the most important items, and discuss the top 3–5 in each column.
Commit to exactly 3 action items
Cap it at 3. Each must have a named owner and a due date before the next retro. If you can't name an owner, it won't get done — cut it.
Review last retro's actions first
Open every retro by checking whether you actually did what you committed to last time. If the same action item appears three retros in a row, it's a systemic problem, not an individual one.
Want a Sprint Retrospective grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How long should a sprint retrospective take?
60 minutes for a 2-week sprint. 90 minutes if there were major incidents, team changes, or release issues worth unpacking. Retros rarely need more than 90 minutes — if they do, split the agenda into two sessions.
Should PMs facilitate the retro or should it be the Scrum Master?
Whoever facilitates should not be the one whose work is under the most scrutiny. If the PM owns prioritization decisions that caused pain, the EM or Scrum Master should facilitate. Rotate facilitation so everyone learns to run them.
What if the team never implements retro action items?
Cap action items at 3 and always start the next retro by reviewing them publicly. If action items consistently go undone, raise it as a meta-issue in the retro itself — it's usually a capacity or prioritization problem, not a motivation one.
What's the difference between a retrospective and a post-mortem?
A retrospective is a regular team health ritual that covers the whole sprint. A post-mortem is a targeted investigation of a specific incident or failure (an outage, a missed launch, a customer escalation). Both use similar formats but have different scopes and triggers.
Other free templates