retro

# Retro A retrospective that actually changes behavior: collect what went **well / wrong / confusing**, dig past symptoms to **root cause**, and walk out with 2-3 owned **actions**. The point isn't to vent — it's to fix the system that produced the outcome. **Grounded in:** *Agile Retrospectives* — Esther Derby & Diana Larsen: set the stage → gather data → generate insight → decide what to do, blamelessly. **Go deeper (The Product Channel):** [The Product Death Cycle](https://sidsaladi.substack.com/p/week-63-the-product-death-cycle-how) ## When to use this - End of a sprint, cycle, or milestone and you want a repeatable retro instead of an unstructured gripe session. - A launch, incident, or project just wrapped (good or bad) and you need a blameless post-mortem. - The same problem keeps recurring and prior retros produced action items nobody did. - A new or distributed team needs a lightweight, async-friendly retro format. - You've collected raw notes/feedback from the team and need them synthesized into themes, causes, and a short action list. ## Before you start (gather these) - **Scope & period:** what are we retro-ing (which sprint/project/incident) and over what dates? - **Raw observations:** the team's well / wrong / confusing notes, OR the source material to derive them (Slack threads, sprint board, incident timeline, survey responses). - **Outcomes/metrics:** what actually happened vs. what was planned — shipped vs. committed, dates, defects, key numbers. - **Pri...