Retrospectives

Your team has just closed a sprint, finished a milestone, or cleaned up after a bad deploy, and someone has put an hour on the calendar called a retrospective. This page covers the kinds of retrospective, four formats for running one, how to facilitate it so it produces actions rather than complaints, and the postmortem you write after an incident. It doesn’t cover planning or reviewing the sprint itself, or what to do when a problem between two people outgrows the meeting.

A retrospective is a structured conversation in which the team examines how it worked rather than what it built. Scrum makes it the event that closes every sprint, with the purpose of planning ways to increase quality and effectiveness. Esther Derby and Diana Larsen’s Agile Retrospectives is a widely used practitioner book on running one, and it splits the meeting into five phases: set the stage, gather data, generate insights, decide what to do, and close the retrospective.

Is it worth an hour every sprint? The closest relative that has been studied at scale is the debrief, or after-action review, used to learn from training exercises and real operations. Tannenbaum and Cerasoli (2013) pooled 46 samples and found that debriefs improved effectiveness over a control group by approximately 25% on average, with similar effects for teams and individuals. Keiser and Arthur (2021) pooled 61 studies and found an overall d of 0.79 across their training outcome measures.

Types of Retrospectives

Retrospectives differ by scope and timing, and the depth should match what the team is looking back on: a two-week sprint needs a quick conversation, a whole project needs a written document.

Sprint Retrospective

Run it at the end of each sprint. The team looks at the sprint it just finished: what worked, what didn’t, and what changes next sprint. Time-box it to 30 to 45 minutes for a sprint of a week or two. The Scrum Guide caps the event at three hours for a one-month sprint and expects it to be shorter for shorter sprints, and a short, regular slot keeps the retrospective a habit the team doesn’t have to justify each time.

Milestone Retrospective

Run it at the end of a major phase: a release, a quarter, or a stage of the project with its own goal. It covers the arc of the phase rather than one sprint: the major successes and failures, how the team worked together, and what to carry into the next phase. Time-box the meeting to 60 to 90 minutes, and budget extra time afterward for the written document.

Write the milestone retrospective down, as themes and commitments rather than meeting notes, because the people who read it later weren’t in the room. Pick two or three themes that explain the phase (a success or a recurring pain point), back each with concrete evidence (a sprint metric, a code review thread, a comment from the project partner), and end each with an action that has a named owner and a timeframe. Tell the story of why things happened; a chronological list of events leaves the reader to find the causes on their own.

Project Retrospective

Run it at the end of the project, over the full lifecycle from the first requirements to delivery. At this scope the useful questions are about the arc, not about any one sprint:

Where did the project surprise you, and how did the team respond?
Which decisions would you make again, and which would you reverse knowing what you know now?
Which habits did the team build, and which did it drop along the way?
What would you tell a team starting a similar project tomorrow?

Pair the team discussion with individual reflection, where each member writes down their own growth, contributions, and lessons, because over a whole project each person’s arc differs from the team’s, and a group conversation only captures the shared part.

Incident Retrospective (Postmortem)

When something breaks, or nearly breaks, in production, run a retrospective focused on that one event. The output is a written postmortem, and the goal is to change the system so the failure is less likely or caught sooner.

Formats

Keiser and Arthur (2021) found that a highly structured review beat a less structured one in the military but did about as well as a less structured one in healthcare, and suggest that effectiveness depends on several characteristics in combination. For a team, that makes picking a format a practical choice rather than a scientific one. Try a few, keep the one that gets your team talking, and switch when the answers start sounding the same. Retromat, Corinna Baldauf’s collection of retrospective activities, has well over a hundred more when these four go stale.

Start, Stop, Continue

This is the simplest format. Each team member contributes to three lists:

Start: things the team should begin doing.
Stop: things the team should stop doing.
Continue: things that are working and should be kept.

After everyone has written, cluster similar items and pick two or three to act on.

4Ls

Each team member reflects on four prompts, from Mary Gorman and Ellen Gottesdiener’s 4Ls technique:

Liked: what did you enjoy or appreciate this sprint?
Learned: what did you learn?
Lacked: what was missing or insufficient?
Longed for: what do you wish had happened?

Use 4Ls after a stressful stretch or a significant event, because “Lacked” and “Longed for” ask how the work felt as well as how the process ran, which gives frustration a place on the board instead of forcing it into a process item.

Timeline

Draw a shared timeline of the sprint or milestone, and have each member add events: technical milestones, good moments, hard moments, surprises. The exercise builds a shared memory and can reveal patterns (“every integration push happens in the last two days of the sprint”).

In Norm Kerth’s version, the participants build the timeline during the meeting. Bjarnason et al. (2013) instead prepared it beforehand from time-stamped evidence in the team’s systems, which saves meeting time and reduces the risk of the incorrect conclusions that reflection from experience alone can produce. Do the same: pull the commits, merged PRs, deploys, and board changes for the period into a draft timeline before the meeting, and let the team annotate it.

Sailboat

Draw a sailboat, a variant of Luke Hohmann’s Speed Boat game, with:

Wind: things pushing the team forward.
Anchors: things slowing it down.
Rocks ahead: upcoming risks.
Destination: the goal.

Use it in the middle of a project, when the team needs to reconnect with why it’s doing what it’s doing. The rocks make it the one format of the four that looks forward, so it doubles as a risk review.

Running a Good Retrospective

How the session runs matters as much as which format it uses. Tannenbaum and Cerasoli (2013) found that debriefs worked better when the participants, the focus and intent, and the level of measurement were aligned, and found a potential effect of facilitation and structure.

Set the Stage

Open with a brief check-in. Ask each person a low-stakes question (“One word for how the sprint went?”) so that everyone has spoken once before the harder topics come up. A person who has already said something tends to find it easier to speak again, and the check-in costs two minutes.

Psychological Safety First

People won’t share what they actually observed if they expect embarrassment or retaliation. Edmondson (1999) defined team psychological safety as a shared belief that the team is safe for interpersonal risk taking, and found it associated with learning behavior in 51 teams in a manufacturing company. The 1999 study grew out of her study of hospital patient-care teams, where members of some teams openly acknowledged a medication error and discussed how to avoid a repeat, while members of others kept it to themselves. Those teams differed not only in the frequency of errors but in how likely an error was to be detected and learned from (Edmondson, 1996). A retrospective where everyone says things went fine may be describing that second kind of team.

A common convention for this is Norm Kerth’s Prime Directive: everyone did the best job they could, given what they knew at the time, their skills, the resources available, and the situation. Read it aloud at the start, because it moves the question from who failed to what made failure likely, and only the second question leads to a change the team can make. Agree on ground rules as well:

What’s said in the retrospective stays there, unless the team decides to write it down.
Observations are about systems and processes, not individuals.
The facilitator invites quieter voices before closing a topic.

Facilitate, Don’t Dominate

Rotate the facilitator role across team members. The facilitator’s job is to run the process, not to share the most opinions: ask questions, group what people contribute, and keep time. Running it from inside the team fits the evidence: Keiser and Arthur (2021) found that the most effective combinations included self-led facilitation with a review aligned to the team.

Make sure every person contributes before open discussion starts, for example by having everyone write sticky notes in silence first. In an open discussion the floor goes to whoever is comfortable taking it, and a teammate who has been carrying a problem alone for weeks is the least likely to interrupt. Derby and Larsen give the facilitator the same job: watch for people talking much more or much less than the others, and make an opening for the quieter ones without putting them on the spot.

Bring the Evidence

Put the records on the table: the board, the merged PRs, CI history, bug counts, and any team health check you ran. Lehtinen et al. (2017) analyzed data from 37 retrospectives held over almost three years in one software organization and found that the teams’ discussions of estimation accuracy contradicted the estimation data in their own task repository. The teams kept discussing it and adding corrective actions, and estimation accuracy didn’t improve. The authors propose bringing fact-based evidence into the meeting; in that organization, bug data would have been readily available and wasn’t used. Keiser and Arthur’s meta-analysis points the same way: objective media for reviewing performance consistently contributed to an after-action review’s effectiveness (Keiser and Arthur, 2021).

Focus on Actions

End every retrospective with actions. For each theme the team picks, define:

What will change? (a specific action, not an intention)
Who owns it? (one person, not “the team”)
By when? (a sprint number or a date)
How will the team know it worked? (a sign someone can observe)

Keep it to three actions at most. Each one competes for time with the sprint’s actual work, and an action that doesn’t get done costs more than the time: it teaches the team that what’s said in the retrospective doesn’t change anything.

Put the actions where the team tracks its other work (the Scrum Guide notes the most impactful ones may go straight into the next sprint’s backlog), and review them at the start of the next retrospective. If one wasn’t done, find out why before adding new ones.

Check whether each action is within the team’s control. Lehtinen and colleagues hypothesize that a team’s improvement proposals for problems outside its control, or too complex to solve at the team level, tend to stay ineffective (Lehtinen et al., 2017). For those, the action is to raise the problem with whoever does control it (the project partner, a manager or an advisor), not to promise a fix the team can’t deliver.

Postmortem Format

For incidents, a lightweight postmortem covers five areas:

Summary: what happened, and what was the impact?
Timeline: a chronological reconstruction of events.
Root cause: what was the underlying cause, not the proximate trigger?
Contributing factors: what conditions made this outcome possible?
Action items: what will prevent recurrence, or catch it sooner?

For the root cause, the 5 Whys technique asks “why did this happen?” repeatedly until the answer is a systemic cause rather than a person. Stop at a condition the team can change (a missing check, an unclear handoff), because the team can add a check or clarify a handoff, but it can’t make a person stop making mistakes. Follow more than one chain of whys when an incident has more than one cause; a fishbone diagram lays out several at once.

Best Practices

Run retrospectives when things are going well, so the meeting isn’t read as a fire alarm and the team has practiced the habit before it needs it.
Split the time-box across the phases before you start (for a 45-minute session, roughly 5 minutes to open, 10 to write, 20 to discuss, and 10 to agree on actions), because discussion expands to fill whatever time is left and the actions get squeezed out.
If a sprint retrospective regularly runs past an hour, switch to a lighter format or narrow the question, because an hour-plus meeting every sprint is the first one cut when a deadline presses.
Share the draft timeline or the health-check results a day ahead, so people arrive having looked at the evidence rather than meeting it for the first time.
Decide as a team before inviting anyone from outside it, such as the project partner or a manager, because people say less in front of someone who evaluates them.
Record the themes and actions within a day, where the team keeps its own documents, so the next retrospective and anyone who joins later can find them. Keep them out of the code repository, which people outside the team read; an action that changes how code gets merged goes into CONTRIBUTING.md as the rule itself.
Close by asking how the retrospective itself went, because the participants are the only ones who can tell when a format has stopped surfacing anything new.

Some Truths About Retrospectives

Don’t skip the retrospective when a deadline is close, even though it’s the meeting that feels most skippable. Planning and review produce something you can point at, so skipping them feels like skipping work; a retrospective produces a conversation, so skipping it feels like reclaiming an hour. What the team loses is the one scheduled moment when a process problem can be raised by the person experiencing it, rather than by whoever gets annoyed enough to bring it up unprompted. Skipping one after a holiday week when nobody touched the code costs little. Skip two in a row and a problem that started in the first sprint has had a month to grow before anyone names it.

Retrospectives can produce their own waste. In the organization Lehtinen et al. (2017) studied, certain topics recurred over a long period, and the authors treat recurring discussions as a potential sign of waste. A team that holds the meeting faithfully can still be going through the motions. When a problem has survived two rounds of team-level fixes, stop re-discussing it in the retrospective and treat it as outside the team’s control, because a third round of the same discussion takes time from problems the team can still fix.

A blameless retrospective can also become a place to avoid an uncomfortable conversation. Framing a problem as a system problem is right whenever a process change could fix it, but when one person has missed commitments sprint after sprint, the system framing lets the team talk around it indefinitely, and the person never hears it directly. That conversation doesn’t belong in a group meeting, where it turns into public blame; have it one-to-one, and read how to hold it and when to escalate.

A written retrospective takes longer than it looks, and the time goes into reconstructing what happened, not into writing. Memory is a weak source for that, which is why the evidence-based timeline above is drafted from records. Keep a short note each sprint, such as a learning journal, and the document at the end becomes a matter of selecting and explaining rather than remembering.

Retrospectives in Industry and Academia

The retrospective is a defined event in Scrum, but the practice predates agile. Tannenbaum and Cerasoli (2013) note that the U.S. Army has used debriefs, or after-action reviews, for decades, and that medical, aviation, and other communities increasingly use them too.

In software operations, Google’s Site Reliability Engineering (SRE) book describes the blameless postmortem as a tenet of SRE culture and documents how Google runs one. Some companies publish their postmortems: GitHub’s monthly availability reports, Atlassian’s review of its multi-day outage, and Stripe’s root-cause analysis of significantly elevated API error rates are examples, and Dan Luu’s list collects many more.

In software engineering research, retrospectives are less studied than they are used. Lehtinen et al. (2017) note that their tangible outcomes have received little research attention despite their widespread use, and both software studies cited on this page are case studies: one organization, and two cases of the evidence-based timeline (Bjarnason et al., 2013). The debrief meta-analyses weren’t designed around software teams (Keiser and Arthur name the military and healthcare among their settings), so treat their effect sizes as a strong hint for a software team rather than a measurement of one.

References

Tannenbaum, S. I., and Cerasoli, C. P. (2013). Do Team and Individual Debriefs Enhance Performance? A Meta-Analysis. Human Factors: The Journal of the Human Factors and Ergonomics Society. https://doi.org/10.1177/0018720812448394
Keiser, N. L., and Arthur, W. (2021). A Meta-Analysis of the Effectiveness of the After-Action Review (or Debrief) and Factors That Influence Its Effectiveness. Journal of Applied Psychology. https://doi.org/10.1037/apl0000821
Bjarnason, E., Hess, A., Doerr, J., and Regnell, B. (2013). Variations on the Evidence-Based Timeline Retrospective Method: A Comparison of Two Cases. 39th Euromicro Conference on Software Engineering and Advanced Applications (SEAA). https://doi.org/10.1109/SEAA.2013.39
Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly. https://doi.org/10.2307/2666999
Edmondson, A. C. (1996). Learning from Mistakes Is Easier Said Than Done: Group and Organizational Influences on the Detection and Correction of Human Error. The Journal of Applied Behavioral Science. https://doi.org/10.1177/0021886396321001
Lehtinen, T. O. A., Itkonen, J., and Lassenius, C. (2017). Recurring Opinions or Productive Improvements: What Agile Teams Actually Discuss in Retrospectives. Empirical Software Engineering. https://doi.org/10.1007/s10664-016-9464-2

Additional Readings

Most of these come from incident review. Read them even if your project never has an incident, because a blameless postmortem is a retrospective run under pressure, with the same rule of studying the conditions rather than the culprit.

Sources and further reading

The Retrospective Handbook, Patrick Kua: a practitioner’s guide to facilitation problems.
How to run a blameless postmortem, Atlassian.
PagerDuty Postmortem Documentation, PagerDuty.
Postmortem Culture: Learning from Failure, Google SRE workbook: a poorly written postmortem compared with the one actually written after the same outage.
Each necessary, but only jointly sufficient, John Allspaw: the argument that complex systems fail without a single root cause.
The Field Guide to Understanding ‘Human Error’, Sidney Dekker: the case against the “bad apple” explanation of failure.

Activities that exercise this

Team Health Assessment: the structured check that gives a retrospective something concrete to discuss.
Learning Journal: the running note that makes a written retrospective tractable.
External Feedback Session: the same reflective habit, with an outside perspective.
Team Dysfunctions Assessment: useful when a retrospective keeps surfacing the same unresolved thing.
Fishbone Diagram: lays out several causes at once for a postmortem’s root-cause section.