What is a retrospective? The complete guide for teams

A retrospective is a recurring meeting where a team looks back at a period of work — usually a sprint, project, or milestone — to discuss what went well, what didn't, and what to change next. The output is not a document; it is a short list of concrete improvements the team commits to trying. Run regularly, retrospectives are the mechanism by which teams get better on purpose instead of by accident.

Where retrospectives come from

The practice predates the word. Norm Kerth's 2001 book Project Retrospectives formalized the idea of structured project reviews and gave the community its most famous sentence — the Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

The same year, the Agile Manifesto baked the habit into its twelfth principle: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Scrum turned that principle into a named event — the sprint retrospective — that closes every sprint.

The word itself is just Latin: retrospectare, "to look back." Teams shorten it to retro.

Retrospective vs. review vs. post-mortem

These three get mixed up constantly. They answer different questions:

The review improves the output. The retrospective improves the system that produces the output. A post-mortem is essentially a retrospective scoped to one painful event — the facilitation techniques are the same.

Why retrospectives matter

A team that never reflects repeats its mistakes at whatever speed it works. The retrospective is the deliberate counterweight, and it earns its meeting slot in four ways:

• Problems surface while they're still small. A two-day code review backlog gets discussed in week two, not in the exit interview six months later.
• Improvement becomes explicit work. "We should communicate better" is a wish. "Sam owns adding a 24-hour review SLA, due Friday" is a change.
• The quiet signal gets through. With techniques like silent writing and anonymous cards, the observation of the least loud person carries the same weight as everyone else's.
• The team owns its own process. Changes the team chooses stick; changes imposed from outside get quietly reverted. Retros are where that choosing happens.

There's a compounding effect here. One retro produces a small improvement. Twenty-six retros a year — the cadence of two-week sprints — produce a team that is meaningfully different from the one that started.

The five phases of a retrospective

Most well-run retros follow the structure popularized by Esther Derby and Diana Larsen in Agile Retrospectives:

1. Set the stage (5 min). Frame the goal, restate the Prime Directive if needed, and get every voice in the room once — even with a one-word check-in or a quick icebreaker question.
2. Gather data (10 min). Collect observations about the period, usually by writing cards onto a shared board. Silent, private writing beats open discussion here: it prevents the first loud opinion from anchoring everyone.
3. Generate insights (15 min). Group related cards, vote on what matters most, and dig into the top themes. The question shifts from what happened to why it happened.
4. Decide what to do (15 min). Turn the top insights into a small number of concrete action items — each with an owner and a due date. Two or three done beats ten forgotten.
5. Close (5 min). Review the commitments, appreciate the honest input, and note how the retro itself could improve.

For a deeper walkthrough with exact timings and facilitation tactics, see the full guide on how to run a sprint retrospective.

Popular retrospective formats

The five phases stay constant; the format changes what prompts the team writes against. Rotating formats keeps the signal fresh:

You can browse all of these with examples and facilitation guides in the retrospective template library.

How often and how long?

Scrum's answer: once per sprint, timeboxed to a maximum of three hours for a one-month sprint and proportionally less for shorter ones. In practice, most teams converge on:

Regularity beats duration. A crisp 45-minute retro every two weeks compounds; a three-hour quarterly reflection marathon gets postponed twice and then cancelled. For your exact sprint length and team size, the retrospective timebox calculator splits the total into a minute-by-minute agenda across the five phases.

Common retrospective mistakes

Most "retros don't work for us" stories trace back to a few patterns:

• No follow-through. Action items are written, never reviewed, and die in a doc. Fix: open every retro by checking the previous items' status — visibly.
• The complaint ceiling. The team vents the same frustrations sprint after sprint because the real blockers sit outside its control. Fix: split themes into we control this and we can only escalate this, and actually escalate the second pile.
• Loudest-voice bias. Open discussion from minute one means the agenda belongs to whoever speaks first. Fix: silent writing and blind voting before any debate.
• Blame theater. Retros that put individuals on trial produce silence, not honesty. Fix: the Prime Directive, anonymous cards, and a facilitator willing to redirect.
• Format fatigue. The same three columns for a year turns reflection into ritual. Fix: rotate formats every few sprints.
• Manager surveillance. If people believe what they say will surface in a performance review, they stop saying it. Fix: the retro belongs to the team; share outcomes, not transcripts.

Do remote and async teams run retrospectives differently?

The structure survives distance well — what changes is the tooling. Remote teams replace the wall of sticky notes with an online retro board; distributed teams across time zones often split the meeting: cards are added asynchronously over a day or two, then a short live session covers only voting, discussion, and decisions.

Two things matter more remotely than in person: hidden input (on a shared screen, everyone sees the first cards and anchors on them — unless the board hides cards during writing) and explicit facilitation (timers and phases do the work that body language does in a room). The full playbook — including a day-by-day async format — is in the remote and async retrospectives guide.

Key takeaways

• A retrospective is a recurring team meeting for improving how the team works — distinct from a review, which inspects what was built.
• The reliable structure is five phases: set the stage, gather data, generate insights, decide, close.
• Output is two or three owned action items, reviewed at the next retro — not a list of ten wishes.
• Formats are interchangeable lenses; rotate them. Cadence and follow-through are what compound.