# Sprint Retrospective

**Framework:** Agile retrospective  
**Use for:** End-of-sprint reflection that turns how the team worked into concrete improvements  
**Time required:** 45–60 minutes at the end of each sprint

---

## How to use this template

1. Run it at the end of every sprint, before planning the next one. The cadence is the point.
2. Review last retro's action items FIRST. Items that never got actioned are the real signal — usually that the retro isn't being taken seriously.
3. Keep it safe. This is about the process, not blame. The moment it becomes a search for who to fault, people stop being honest and the retro dies.
4. The output is action items with owners, not a list of complaints. A retro that produces no change is venting.
5. Pick ONE or TWO changes to actually make. Trying to fix everything fixes nothing.

---

## Header

| Field | Details |
|-------|---------|
| Team | [Name] |
| Sprint | [Number / name] |
| Date | [Date] |
| Facilitator | [Name] |
| Attendees | [Names] |

---

## Last retro's action items — review first

*Start here, every time. Unactioned items from last time are the most important data in the room.*

| Action agreed last retro | Owner | Status |
|--------------------------|-------|--------|
| [What we committed to] | [Name] | [Done / In progress / Not started] |
| [What we committed to] | [Name] | [Done / In progress / Not started] |

---

## What went well

*Name it so you keep doing it. Reinforcement is half the value of a retro.*

- [Something that worked — a practice, a decision, a save]
- [Something that worked]
- [Something that worked]

---

## What didn't go well

*Honest, specific, and about the process — not the people.*

- [Friction, miss, or failure — what happened, not who]
- [Friction, miss, or failure]
- [Friction, miss, or failure]

---

## What still puzzles us

*Optional. Things that happened that the team doesn't yet understand. Naming a puzzle is the first step to solving it.*

- [Something unexplained — a metric that moved, an outcome nobody predicted]

---

## Sprint metrics (optional gut-check)

| Metric | This sprint | Trend |
|--------|-------------|-------|
| Committed vs completed | [X of Y] | [↑ / → / ↓] |
| Velocity | [points] | [vs recent average] |
| Carryover into next sprint | [items] | [↑ / → / ↓] |
| Notable burndown shape | [Flat early? Cliff at the end?] | — |

---

## Root causes & insights

*Push past symptoms. "We were slow" is a symptom. "Reviews sat for two days because there's no review SLA" is a cause you can fix.*

1. [Symptom → likely root cause]
2. [Symptom → likely root cause]

---

## Action items — the output

*Cap at one or two. Each has a single owner and a date. This is the only part of the retro that changes anything.*

| Change to make | Owner | By when |
|----------------|-------|---------|
| [Specific, doable change] | [Name] | [Date / next sprint] |
| [Specific, doable change] | [Name] | [Date / next sprint] |

---

*A retrospective without action items is therapy, not improvement. More on Agile, Scrum, and Kaizen at biztechprimer.com.*