| 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
- Define the review window and bring objective evidence such as delivery outcomes, lead time, defects, incidents, blockers, rework, and changed commitments.
- Create space for participants to identify what helped, what hurt, and what surprised them without assigning personal blame.
- Separate systemic patterns from one-off events and distinguish evidence from interpretation.
- Trace important friction to process, ownership, information, tooling, dependency, or decision conditions that the team can influence.
- Prioritize one or a few improvements with clear expected benefit instead of producing a long wish list.
- Assign an owner and observable success signal for each selected experiment or change.
- Review prior retrospective actions and either close, continue, revise, or abandon them explicitly.
- 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.
