How to Run Retrospectives That Actually Improve Things

It is the fifth retrospective in a row where the flaky pipeline comes up. The team discusses it with feeling, everyone agrees it is frustrating, and the meeting moves on. Nothing is written down, nobody owns a fix, and next month’s retro already has its first topic. At this point the meeting is less a retrospective than a subscription. This guide shows how to run retrospectives that end with something changing.

Teams in this situation often conclude that retros do not work, when the real problem is how they run retrospectives. Usually the retros are fine in principle; they are just missing the part where something is decided, owned, and checked. If your team has quietly stopped expecting anything from retros, the structure below is designed to win that trust back.

What a Retrospective Is For

The Scrum Guide defines the Sprint Retrospective as the event where the team inspects how the last sprint went with regard to individuals, interactions, processes, tools, and its definition of done, then identifies the most helpful changes to improve effectiveness. The timebox is up to three hours for a one-month sprint, and usually shorter for shorter sprints.

Project management has a parallel practice. The PMBOK Guide treats lessons learned as an organizational asset, recorded in a lessons learned register and consulted when planning future work, so the organization does not pay for the same lesson twice.

Both describe the same goal: the measure of a retro is what changes by the next one.

Run It as an Improvement Loop

The plan-do-check-act cycle is the simplest useful frame. It originated with statistician Walter Shewhart and was popularized by W. Edwards Deming, who preferred “study” to “check” because the point is to learn from results, not just confirm success or failure. The Deming Institute explains the distinction.

Mapped onto a sprint rhythm: the retro plans a process change, the sprint does it, and the next retro studies the result and decides what to do next. A retro that never looks back at its previous change has skipped half the loop, which is why checking the last experiment comes first on the agenda below.

Prepare for Twenty Minutes

The facilitator does a short amount of preparation before the session:

• Pull three numbers the team already tracks, for example cycle time, escaped defects or incidents, and how long blockers waited before someone picked them up.
• Write a short timeline of the sprint: releases, incidents, scope changes, absences. Memory smooths over events; a timeline does not.
• Find last retro’s experiment card so its status can open the meeting.
• Set the ground rule in the invite: the session examines the process, not individuals.

Data does not replace people’s experience, but it anchors the discussion. “Builds felt slow” becomes “median build time went from 9 to 14 minutes this sprint”, which is much easier to act on.

A 60-Minute Agenda

Discussing in pairs before the whole group matters. It gives quieter engineers space to form and voice observations that the most confident voices would otherwise crowd out. Silent writing on sticky notes or a shared board does the same job for remote teams.

One Experiment, One Owner

EXPERIMENT CARD
Constraint:   what slowed us down, in one sentence.
Experiment:   the smallest change that could fix it.
Owner:        one name.
Metric:       how we will know whether it worked.
Review date:  the next retrospective.
Result:       not run / ran, no change / ran, improved / ran, made it worse.

Why only one? Improvement work competes for the same scarce spare time in a sprint. Three actions usually means each gets a third of the attention, and often none gets finished. One well-chosen experiment that actually runs teaches the team more than a list of good intentions. If the team has a second urgent improvement, it can be the next retro’s experiment.

Why one owner? Shared ownership of an improvement action tends to mean nobody feels responsible for starting it. The owner does not have to do all the work, but they make sure it happens and report back.

An Experiment That Failed, Usefully

Failed experiments are part of the loop, not a sign that it is broken. Here is how one might play out.

A team names constant interruptions as its biggest constraint. The experiment: no meetings on Wednesdays. The metric: the number of uninterrupted two-hour focus blocks per engineer per week, read from calendars and a quick self-report. The owner books the change and the review date.

Two sprints later, the review is honest: meetings on Wednesdays fell to almost zero, but focus blocks barely moved. Studying why, the team finds that most interruptions were never meetings. They were chat messages and support escalations arriving throughout the day. The experiment did not fix the problem, but it cheaply ruled out the most obvious cause.

The next experiment targets the real source: one engineer per sprint, on rotation, takes all support questions and chat escalations so the others can work uninterrupted. Two sprints later, focus blocks are up noticeably, and the rotation becomes a working agreement.

Without the review step, the team would have declared no-meeting Wednesdays a success because meetings went down, and the real constraint would have stayed in place. That is why the result field on the card includes “ran, no change”: it is one of the most useful results a retro can produce.

Prompts for Finding the Constraint

The constraint step is where many retros drift into general complaining. Specific prompts keep it grounded:

• “Where did work wait the longest this sprint, and what was it waiting for?”
• “What did we do more than once that we should only have done once?”
• “Which surprise cost us the most time?”
• “If we could remove one step from how we work, which would it be?”
• “What did we know at the start of the sprint that we did not act on?”

Ask pairs to pick their single strongest answer, then compare across pairs. Patterns usually appear quickly, and a constraint mentioned independently by three pairs is a good candidate for the experiment.

For remote teams, run the same prompts in a shared document or board, with a few minutes of silent writing before discussion. It also lets people in awkward timezones add thoughts before the call.

How Retros Fail, and the Fixes

When a retro uncovers friction between people, it has moved beyond what the format can handle. The approaches in how to handle conflict on an engineering team are the right tools; a group retro is not.

Check the Loop Once a Month

Four signals tell you whether retros are working:

• Experiment completion rate: of the last six cards, how many were actually run? More than half suggests the loop is alive.
• Metric movement: after an experiment ran, did its metric change? Some experiments will fail, which is fine. Experiments that never run are the real problem.
• Repeat topics: any issue that appears in three consecutive retros means the loop is broken somewhere specific.
• Lessons reused: does planning ever consult past lessons? A register that nobody reads is a diary, not an asset.

Retros are also a natural place to review outcome hypotheses, checking whether shipped work actually moved the metrics it was meant to, as described in delivering value vs shipping features. And the team’s working agreements from kickoff should be reread here periodically; how to run a project kickoff explains where they come from.

Retros at the End of a Project

Not every team runs on sprints, and the loop works at project scale too. My own habit is to hold a retrospective at the end of every project. No project runs perfectly; surprises are normal, and they affect what gets delivered and how well. In the retro we discuss what happened, and we document the learnings so the same problem does not recur on the next project. That documentation is the project-scale equivalent of the lessons learned register.

I also use the retro to recognize people. When someone has gone above and beyond to make a project succeed, I send them kudos. A retro that only examines problems can start to feel like a review of failures; ending with specific recognition reminds the team that the session is about getting better together.

Retrospectives and Postmortems

A retrospective is a recurring session about how the team works. A postmortem is triggered by a specific incident and analyzes one failure in depth. They run on different triggers, but both should end with owned actions, and both feed the same record of lessons learned. If an incident happened during the sprint, reference the postmortem in the retro rather than redoing it.

When to Skip or Delay a Retro

During an active crisis, use short daily huddles and hold the retro once things are stable and the timeline is clear. A brand-new team with only a sprint or two of shared history may not have enough data yet; light check-ins work better until it does. Atlassian’s retrospective play offers alternative formats if the standard one starts to feel stale. For the rest of the delivery toolkit, from kickoffs to prioritization, see delivery and process.

FAQ

How do you run a sprint retrospective?

Prepare three metrics, a sprint timeline, and the previous experiment card. In 60 minutes, review last time’s experiment, look at the data, identify the single biggest constraint, choose one small experiment to address it, and write a card with one owner and a review date. Review that card at the next retro.

What makes a retrospective effective?

It ends with one owned experiment that is reviewed at the next session. Effectiveness is decided after the meeting, by whether the experiment ran and what it changed. Data-based preparation, pair discussion, and limiting each retro to one experiment are the habits that produce this.

What is the difference between a retrospective and a postmortem?

A retrospective is a scheduled, recurring review of how the team works. A postmortem is an incident-driven analysis of one specific failure. Both should end with owned actions and feed the same lessons learned record.

How long should a retrospective be?

About 60 minutes works well for a two-week sprint and a team of up to around ten people. The Scrum Guide allows up to three hours for a one-month sprint, though few teams need that much. Whatever the length, the session should end with the experiment card written.

Last updated on 10 October 2026