Retrospective
Help a team reflect productively and leave with a small number of concrete, owned improvements — not a venting session.
When to use
- End of a sprint, milestone, project, or quarter.
- Turning messy retro notes/transcript into a clean writeup.
- Designing a retro format/agenda.
Note: for incidents/outages use postmortem (blameless, root-cause focused) instead.
Inputs to gather
- What's being retro'd and the timeframe; who participated.
- Raw input if any (notes, sticky-note dump, transcript), or run a structured prompt.
Process
- Pick a frame — What went well / What didn't / What to try, or Start–Stop–Continue, or Mad–Sad–Glad.
- Group raw input into themes; don't list every duplicate sticky.
- Keep it blameless — focus on systems and process, not individuals.
- Surface the 2–4 highest-leverage improvements, not a wishlist. Each becomes an action.
- For every action: owner, concrete next step, due date, and where it's tracked.
- Revisit prior retro actions — were they done? Open loops kill trust in retros.
Output format
## Retro — {{team/project}} · {{period}}
### What went well
- {{theme}}
### What didn't / challenges
- {{theme}}
### Action items
| Action | Owner | Due | Status |
| --- | --- | --- | --- |
### Carryover from last retro
- {{item — done? / still open}}
Keep actions few and real. A retro with 12 actions has zero.