← All Templates

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.

7 slides Scrum Masters & Dev Teams Free template

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

  1. 1
    Title & Sprint Number

    Sprint number, team name, and date range. Creates a clear historical record.

  2. 2
    Sprint Summary

    Sprint goal, points completed vs planned, carryover, and velocity trend.

  3. 3
    What Went Well

    Celebrate wins with specific examples. Reinforces positive practices.

  4. 4
    What Didn't Go Well

    Honest assessment of problems with root causes identified.

  5. 5
    Action Items

    Specific improvements with owners and deadlines. The most important slide.

  6. 6
    Sprint Metrics

    Quantitative data: velocity, cycle time, bug rate, review time, deploy count.

  7. 7
    Next Sprint Focus

    Sprint goal, key priorities, and capacity notes for the upcoming sprint.

Complete Markdown Template

Copy and paste into Slidepicker
Markdown
# 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 Free

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.