Sprint Retrospective
Run a structured sprint retro that leads to real improvements. This 7-slide template covers sprint summary, what went well, what to improve, concrete action items with owners, sprint metrics, and the next sprint focus.
Who This Template Is For
This template is designed for scrum masters, engineering managers, and agile teams running sprint retrospectives. Use it when you need to:
- ✓ Facilitate a structured, productive sprint retrospective
- ✓ Turn team feedback into concrete, assigned action items
- ✓ Track sprint metrics and identify improvement trends over time
- ✓ Create a visual record of retro outcomes for accountability
Slide-by-Slide Breakdown
- 1Title & Sprint Number
Sprint number, team name, and date range. Creates a clear historical record.
- 2Sprint Summary
Sprint goal, points completed vs planned, carryover, and velocity trend.
- 3What Went Well
Celebrate wins with specific examples. Reinforces positive practices.
- 4What Didn't Go Well
Honest assessment of problems with root causes identified.
- 5Action Items
Specific improvements with owners and deadlines. The most important slide.
- 6Sprint Metrics
Quantitative data: velocity, cycle time, bug rate, review time, deploy count.
- 7Next Sprint Focus
Sprint goal, key priorities, and capacity notes for the upcoming sprint.
Complete Markdown Template
Copy and paste into Slidepicker# Sprint 24 Retrospective
## Payments Team
**January 13 - January 24, 2025**
---
# Sprint Summary
**Sprint Goal:** Ship recurring billing v2 and resolve payment failure backlog.
- **Planned:** 38 story points across 14 tickets
- **Completed:** 34 story points across 12 tickets (89% completion)
- **Carried over:** 2 tickets (payment retry logic, webhook monitoring dashboard)
- **Unplanned work:** 4 points for critical hotfix on currency conversion rounding error
- **Sprint velocity trend:** 32 → 36 → 34 (stable)
---
# What Went Well
- **Recurring billing v2 shipped on time** - Core functionality deployed Wednesday, 2 days ahead of sprint end. Zero rollbacks.
- **Pair programming sessions** - Jake and Amara paired on the subscription upgrade flow and shipped it 40% faster than estimated.
- **Improved test coverage** - Added 47 integration tests for the billing engine. Coverage went from 62% to 81%.
- **Cross-team collaboration** - Frontend team proactively flagged a UX issue in the billing portal before it reached QA, saving an estimated 2-day delay.
- **On-call was quiet** - Only 1 page this sprint (down from 5 last sprint). Previous retro action items on alerting tuning paid off.
---
# What Didn't Go Well
- **Payment retry logic was underestimated** - Estimated at 5 points, actual complexity was closer to 13 due to edge cases with expired cards and 3D Secure re-authentication. Carried to next sprint.
- **The currency conversion hotfix** consumed a full day of unplanned work for 2 engineers. Root cause: insufficient test coverage for non-USD currencies.
- **Sprint planning ran 30 minutes over** because ticket descriptions were incomplete. Engineers had to ask clarifying questions during the meeting that should have been answered in the tickets.
- **Staging environment was down for 4 hours** on Tuesday due to a database migration conflict. Blocked QA testing for the afternoon.
- **Documentation debt** - We shipped recurring billing v2 without updating the API docs. Docs are now a week behind.
---
# Action Items
- **Add multi-currency test suite** - Prevent future currency conversion bugs. Automated tests for all 12 supported currencies. *Owner: Amara. Due: Sprint 25.*
- **Improve ticket quality bar** - All tickets must include acceptance criteria and edge cases before sprint planning. PM to review tickets 2 days before planning. *Owner: Nadia (PM). Starting: Next sprint.*
- **Staging environment monitoring** - Set up alerts for database migration conflicts. Add pre-merge staging health check to CI. *Owner: Jake. Due: Sprint 25.*
- **Docs-as-code sprint rule** - No feature ticket is marked done until documentation is updated. Adding "docs updated" to the definition of done. *Owner: Team agreement. Effective immediately.*
---
# Sprint Metrics
- **Velocity:** 34 points (target: 35, within range)
- **Cycle time:** 3.2 days average (down from 4.1 last sprint)
- **Bug escape rate:** 1 production bug (currency rounding)
- **PR review time:** 4.8 hours average (target: under 6 hours)
- **Deploy count:** 8 production deploys this sprint
- **On-call pages:** 1 (down from 5, improving trend)
- **Test coverage:** 81% (up from 62%)
---
# Next Sprint Focus
**Sprint 25 Goal:** Complete payment retry logic, ship webhook monitoring dashboard, and start PCI compliance preparation.
**Key priorities:**
- Finish payment retry logic (carried over, already 60% complete)
- Webhook monitoring dashboard (carried over)
- PCI DSS assessment preparation (new initiative, 3 tickets scoped)
- Multi-currency test suite (from retro action items)
**Capacity note:** Amara is out Monday-Tuesday for a conference. Adjusted point target to 32.
**Sprint planning: Monday, January 27 at 10:00 AM** Use This Template Now
Open Slidepicker, paste the Markdown above, and your sprint retro slides are ready. Duplicate and update every two weeks for a consistent retrospective process.
Open Slidepicker - It's FreeRelated Templates
Weekly Team Sync
7 slidesKeep your team aligned with progress updates and blockers.
For: Team Leads
Project Kickoff
8 slidesAlign your team on goals, scope, timeline, and responsibilities.
For: Project Managers
Quarterly Business Review
10 slidesPresent revenue, metrics, and goals to stakeholders.
For: Executives
Frequently Asked Questions
How long should a sprint retrospective be?
For a 2-week sprint, aim for 45-60 minutes. This 7-slide template is designed for a 30-minute structured discussion followed by 15-30 minutes of open conversation. If retros consistently run over, the team may be trying to solve problems in the meeting instead of identifying them for follow-up.
How do I make sure action items actually get done?
Every action item needs an owner and a deadline. Review the previous sprint's action items at the start of each retro. If items are repeatedly carried over without progress, the team needs to discuss whether they are truly a priority or should be dropped. This template includes owners and due dates for every action item.
What metrics should I track in a sprint retro?
Focus on metrics that reflect team health and efficiency: velocity (trend, not absolute), cycle time, bug escape rate, PR review time, and on-call incidents. Track the same metrics every sprint so you can spot trends. Avoid adding too many metrics; 5-7 is the sweet spot.