Retrospective

---
name: retrospective
description: Facilitate a retrospective that turns recent delivery evidence into a small number of owned process experiments or decisions without becoming a blame session or ritual complaint list.
---
# Retrospective

Use after an iteration, milestone, incident, release, or meaningful delivery period when the team can improve how it works.

## Procedure
1. Define the review window and bring objective evidence such as delivery outcomes, lead time, defects, incidents, blockers, rework, and changed commitments.
2. Create space for participants to identify what helped, what hurt, and what surprised them without assigning personal blame.
3. Separate systemic patterns from one-off events and distinguish evidence from interpretation.
4. Trace important friction to process, ownership, information, tooling, dependency, or decision conditions that the team can influence.
5. Prioritize one or a few improvements with clear expected benefit instead of producing a long wish list.
6. Assign an owner and observable success signal for each selected experiment or change.
7. Review prior retrospective actions and either close, continue, revise, or abandon them explicitly.
8. Preserve useful decisions and experiments in the team's durable operating record.

## Decision rules
- Retrospectives are for learning and improvement, not performance grading.
- Repeating the same action item without evidence of change is a process smell.
- Not every complaint deserves an action; prioritize leverage and ownership.
- Celebrate working practices worth preserving, not only failures.

## Quality gate
The retrospective is useful when it produces evidence-backed learning, a small set of owned improvements or explicit decisions, prior actions are reconciled, and participants can see how the next period will test whether anything actually improved.