Retrospective

Origin & evolution

Norm Kerth formalised the practice in Project Retrospectives: A Handbook for Team Reviews (2001), drawing on the older engineering "project postmortem🩻PostmortemDevOps & PlatformA post-incident reviewView reference →" but reframing it as forward-looking learning. Kerth's lasting contribution is the Prime Directive, the opening statement of intent: "Regardless of what we discover, we understand and truly believe that everyone did the best job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." The line manufactures the psychological safety the meeting depends on, years before that term entered common use. Without it, a retrospective slides into fault-finding and people stop being candid.

Agile absorbed the practice and made it routine. Where Kerth ran retrospectives at the end of a long project, Scrum folded a short retro into the close of every sprint, turning reflection from a rare post-mortem into a regular cadence. That shift changed the stakes per meeting (any single retro matters less) and raised the value of the habit (small corrections compound across iterations).

Esther Derby and Diana Larsen gave the meeting its working structure in Agile Retrospectives: Making Good Teams Great (2006). Their five stages, set the stage, gather data, generate insights🔦InsightUser ResearchA synthesised finding from researchView reference →, decide what to do, and close, fixed a flaw in unstructured retros, which tended to leap from a complaint straight to a fix without examining cause, or to surface problems and end without committing to any change. The "decide what to do" stage is the one teams most often skip, and skipping it is why a team can run retrospectives for a year and improve at nothing.

How it works in practice

A six-person team closes a two-week sprint that shipped late. The facilitator opens with the Prime Directive, then runs a "gather data" round where everyone posts events on a timeline; a pattern emerges that three stories were blocked for days waiting on a single reviewer. In "generate insights" the team asks why and finds the reviewer was the only person who understood the payments module. Without the data stage they would have blamed the late ship on "poor estimation". The "decide" stage produces one concrete action with an owner: pair two engineers on the payments module next sprint to spread the knowledge. One change, owned, reviewed at the next retro. By skipping the urge to generate ten action items, the team actually does the one that matters.

Retrospective vs. its neighbours

• Ceremony is the general category of recurring agile meeting (standup, planning, review, retro). A retrospective is the specific ceremony aimed at process improvement. The standup coordinates today's work; the retro changes how the work gets done. The graph types a retro as a kind of ceremony🔔CeremonyTeam & OrganisationA recurring team ritual (standup, planning)View reference →.
• Postmortem is typically triggered by a single incident🚨IncidentDevOps & PlatformA production incidentView reference → or a finished project and run once, focused on a specific failure. A retrospective is recurring and examines a whole period of normal work, not just a crisis. The two share Kerth's blameless stance, and a postmortem is the event-driven cousin of the scheduled retro.
• Learning is the durable output a retrospective is meant to produce, the captured insight that outlives the meeting. A retro that generates no recorded learning and no owned action was, by Derby and Larsen's structure, only four-fifths complete.

In the graph

In the Unified Product Graph, a retrospective sits in the team and organisation region as a recurring ceremony, linked to the team that runs it through team_reflects_in_retrospectiveTeamreflects inRetrospectivehierarchy. Modelling it as the team's own reflective practice keeps it distinct from incident-driven postmortems while preserving the shared blameless lineage. The structure also exposes the field's core failure mode: a retrospective that connects to no resulting decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference →, action, or learning is visibly a meeting that happened without changing anything, exactly the empty-ritual outcome🏆OutcomeStrategyA desired business or user outcomeView reference → Derby and Larsen's "decide what to do" stage exists to prevent.