Retrospective

Origin & evolution

The retrospective as a disciplined team practice was given its foundational shape by Norman Kerth, whose 2001 book Project Retrospectives: A Handbook for Team Reviews described techniques for facilitating honest, psychologically safe reviews of completed projects. Kerth introduced the Prime Directive, the agreement teams make before beginning: everyone did the best they could given what they knew and the resources they had at the time. That framing shifts the conversation from blame to learning🧠LearningValidationAn insight gained from an experimentView reference →.

The ceremony was embedded into the software delivery world through Extreme Programming and Scrum in the late 1990s and early 2000s. Scrum's Sprint Retrospective, held at the close of every sprint, made the practice routine. Esther Derby and Diana Larsen's 2006 book Agile Retrospectives: Making Good Teams Great became the practitioner's guide for facilitators who wanted structured activities beyond a simple What Went Well/What Didn't round-table, and it remains widely read today. A second edition followed in 2024.

How it works in practice

A well-facilitated retrospective moves through five stages, as described by Derby and Larsen: Set the Stage, Gather Data, Generate Insights🔦InsightUser ResearchA synthesised finding from researchView reference →, Decide What to Do, and Close the Retrospective. In practice, most teams work with a simplified three-column format:

• What Went Well: practices, behaviours, or outcomes🏆OutcomeStrategyA desired business or user outcomeView reference → the team wants to preserve and amplify. These are the things to protect.
• What Didn't Go Well: friction, failures, and missed opportunities🚪OpportunityDiscoveryA validated gap worth solvingView reference → worth examining. Naming them precisely is more useful than listing them vaguely.
• Action Items: specific, owned, time-boxed improvements the team commits to trying in the next cycle.

Some teams add a fourth column, Learnings, to capture the insight behind an action item so that the lesson is recorded even when the action is complete.

A concrete example. A six-person mobile engineering team ends a two-week sprint with a retrospective. Under What Went Well they note that pair programming on the new notification module cut review time by half and that the team's daily standup stayed under fifteen minutes throughout. Under What Didn't Go Well they surface two items: the QA environment was unavailable for three days mid-sprint because of an unannounced infrastructure change, and two tickets arrived from the backlog without acceptance criteria, causing mid-sprint renegotiation. Under Action Items they record three things: the tech lead will set up a monitoring alert on the QA environment with an escalation path; the product manager will add a checklist to the ticket template requiring acceptance criteria before any ticket enters sprint planning; the team will try mob programming for the next complex feature⭐FeatureProduct SpecificationA product capability or featureView reference → to see whether it reproduces the pairing benefit at larger scale. Each item has a named owner and a date.

The single most important quality of action items is that they are reviewed at the start of the next retrospective. Without that review loop the ceremony is a warm-up and not the mechanism of improvement it is meant to be.

When to use it (and when not)

The retrospective fits any team doing time-boxed iterative delivery: software sprints, content production cycles, campaign flights, and quarterly planning cadences all benefit from a structured lookback. It is particularly valuable when a team is new, when a team has just experienced a significant failure, or when a long-running team has become complacent and stopped improving.

The ceremony earns its keep less well when psychological safety is low. If team members do not feel safe raising real problems, the What Didn't Go Well column fills with surface observations👁️ObservationUser ResearchA specific behaviour or statement observedView reference → while the actual issues go unspoken. A poorly facilitated retrospective can reinforce silence faster than no retrospective at all. The other common failure mode is action item inflation: teams generate a list of fifteen improvements, carry none of them forward, and arrive at the next retrospective to generate fifteen more. Limiting action items to two or three per cycle and reviewing them publicly creates the accountability that makes the ceremony useful.

In the Unified Product Graph

The retrospective is a matrix framework in the team process category. Its columns map onto two entity types in the Unified Product Graph:

• What Went Well and What Didn't Go Well both become outcome🏆OutcomeStrategyA desired business or user outcomeView reference → and need🫀NeedUserA user need, pain, desire, or constraintView reference → entities respectively. A positive outcome the team wants to protect is modelled as an outcome🏆OutcomeStrategyA desired business or user outcomeView reference →: something the team has delivered or experienced. A problem or friction point is modelled as a need🫀NeedUserA user need, pain, desire, or constraintView reference →: something the team still requires in order to work well.
• Action Items and Learnings both become learning🧠LearningValidationAn insight gained from an experimentView reference → entities: the team's captured knowledge and committed changes that flow from inspecting the cycle.

Modelling retrospective outputs this way means a need🫀NeedUserA user need, pain, desire, or constraintView reference → surfaced in a retrospective can connect to the team's backlog, and a learning🧠LearningValidationAn insight gained from an experimentView reference → entity can be linked to the sprint or project phase it came from. The retrospective stops being a set of sticky notes that disappear after the session and becomes a record in the graph, traceable to the work and the people who produced it.