Retrospectives: what they are, how to run one, and which format to pick

Retrospectives are regular sessions where a team looks back at the work it just finished and agrees what to change. A good one moves through five phases: set the stage, gather data, generate insights, decide what to do, and close, and ends with one or two agreed actions, each with a named owner and a date.

Most teams run retrospectives. Far fewer run ones that change what happens next sprint, and the difference is almost always facilitation, not the format you pick. This guide covers the whole thing: what a retrospective is and what it is for, the five phases a good session moves through, a ready-made 60-minute agenda you can copy, the common formats and when to reach for each, and the anti-patterns that quietly kill the habit. It applies to scrum teams and to any team that finishes work in cycles.

What a retrospective is

A retrospective is the moment a team stops to ask a deceptively simple question: how are we working, and how could we work better? It is a regular, protected slot, usually at the end of a sprint or a piece of work, where the people who did the work look back together and agree on what to change.

Its job is narrow and concrete: find the one or two things slowing the team down, and agree on a change. That is it. A retro is not a status meeting, not a blame session, and not a place to re-plan the backlog. Get the habit right and the “culture of continuous improvement” everyone talks about takes care of itself, because the team can see its own decisions showing up in how the next sprint runs.

The output is the test. A session that ends in a good conversation and nothing else has not finished; one that ends with two changes, each owned by a named person, has. That is the whole difference between a team that improves and a team that has been meeting about improvement for a year. If you specifically want the scrum event and where it sits in the sprint, what is a sprint retrospective covers it; everything else here applies to any team.

The five phases of a retrospective

The most durable structure comes from Esther Derby and Diana Larsen’s Agile Retrospectives, which frames every good session as five phases:

1. Set the stage. Open the room, state the goal, and make it safe to speak. Five minutes is enough: a one-line goal, the prime directive, and a short check-in question.
2. Gather data. Get everyone’s view of what actually happened onto the table, facts and feelings both. Take silent written input first, so the board reflects the team rather than whoever spoke first.
3. Generate insights. Look for the patterns and root causes behind the data, not the symptoms. Group the related notes, vote on what matters most, and keep asking why until you reach something the team can actually change.
4. Decide what to do. Turn the best insight into one or two concrete actions. Each gets a single owner and a date before anyone leaves the room.
5. Close. Confirm the actions, thank the team, and check how the retro itself went. A quick score out of five tells you whether the format is still earning its hour.

The phases matter more than any single template. Whatever format you run, it should move the team through these five steps in order. Skipping “gather data” straight to “decide what to do” is how retros end up solving the loudest person’s pet problem instead of the real one.

A 60-minute retrospective agenda

Sixty minutes is enough for a focused sprint retro. Here is a worked agenda that maps straight onto the five phases:

• 0:00 to 0:05, Set the stage (5 min). Restate the goal in one line, read the prime directive, and ask a short check-in question to warm the room.
• 0:05 to 0:20, Gather data (15 min). Everyone adds their own notes silently first, then you make the board visible. Silent writing stops the discussion anchoring on whoever speaks first.
• 0:20 to 0:35, Generate insights (15 min). Group the related notes, dot-vote on what matters most, and dig into the top one or two. Keep asking “why” until you reach something the team can actually change.
• 0:35 to 0:50, Decide what to do (15 min). Agree on one or two actions. Each gets a single owner and a date.
• 0:50 to 1:00, Close (10 min). Read the actions back, thank the team, and take a quick temperature on the session itself.

Adjust the split for your team: a tense sprint may need more time in “gather data”, a smooth one can spend it on “decide what to do”. The point is to keep every phase timeboxed so you always reach agreed actions before the hour is up.

Plan your retrospective: a pre-retro checklist

A good session is mostly won before anyone joins the call. Run through this checklist in the day before your retro. It doubles as a handover if someone else is facilitating.

• Review last retro’s actions. Pull up the previous session’s commitments and note which landed. This is the first thing you will cover.
• Pick a format. Choose the one that fits this sprint, not your habit (see the next section).
• Book the time and the people. Protect a full slot on the calendar and make sure the whole team, and only the team, is invited.
• Prep the board and questions. Set up the columns or template in advance and write your check-in question so you are not improvising at the start.
• Decide how input is collected. Plan for silent, written input first, anonymous if the topic is sensitive.
• Have the prime directive ready. Know how you will open and set the tone for safety.
• Plan for actions. Decide where actions will be recorded and who confirms owners and dates before you close.

Common retrospective formats

Format is a choice, not a default. What fits depends on what the team needs this week: a process tune-up, an honest read on morale, or a longer look at where the work is heading. Five formats cover most situations.

Start Stop Continue

Three columns: what to start doing, what to stop, what to keep. It is the quickest format to explain and the easiest to convert into actions, because each column is already phrased as a decision. Reach for it when the team is steady and only wants to tune its process, and for a first retrospective, where nobody should be learning a framework and reflecting at the same time. The Start Stop Continue template sets the three columns up for you.

Mad Sad Glad

Three columns for how the work felt: what made people angry, what disappointed them, what they were pleased with. It surfaces the emotional temperature rather than the process detail, which is what you want after a hard or unusual sprint when how people feel is the story. It works less well as a standing default, because a team that is basically fine will fill it with mild answers. See the Mad Sad Glad template.

Sailboat

One picture: the wind pushing the boat along, the anchors holding it back, the rocks ahead, and the island the team is sailing toward. The metaphor gets goals, risks and blockers onto the same board, which suits a longer look back over a release or a quarter more than a routine two-week check. It takes more explaining than a three-column format, so budget a few extra minutes at the start. The Sailboat template has the board drawn already.

4Ls

Four prompts: liked, learned, lacked, longed for. The middle two are the useful part, as they pull out what the team now knows and what it wished it had, which the tidier process formats tend to skip. Good after a project, a release, or anything the team has never done before. See the 4Ls template.

Rose Bud Thorn

Three prompts: roses for what went well, buds for early signs of something promising, thorns for what hurt. The bud column is what makes it worth running. It is one of the few formats that asks the team to name something that is not yet a win or a problem. Use it when a retro has drifted into a problem list and you want the positives and the near future back on the board. The Rose Bud Thorn template is set up for it.

Starfish widens the same idea to five signals (keep, more, less, start, stop) when start-and-stop feels too blunt, and the full set of retrospective templates covers the rest. Twenty formats grouped by the problem they fix are in retrospective games.

Two rules hold whichever you pick. A simple format run well beats a clever one run badly, so don’t reach for the sailboat when three columns would have done the job. And vary it: a team that runs the same board every sprint stops seeing new things and starts filling in a form.

Then there is the one thing that matters more than the columns. Take silent, written input before any discussion. When everyone adds their notes first, the loudest voice stops setting the agenda and the quieter, more careful observations actually get heard.

Facilitation tips

The facilitation matters more than the format. Three things carry most of the weight:

Open with the prime directive. Remind everyone that, regardless of what we discover, everyone did the best job they could with what they knew at the time. It is not a platitude. It is the sentence that makes it safe to raise the real problem.

Keep the opening short. Under five minutes. The goal is psychological safety, not a second status meeting. If people feel safe, the honest material surfaces on its own.

Draw out the quiet voices. The loudest person is rarely the one with the most important observation. Silent writing before discussion, anonymous input where needed, and dot-voting all move the session away from “whoever talks most wins” and toward what the team actually thinks. Run it so the quietest person in the room can still set the agenda.

Retrospectives beyond scrum

Retrospectives reached most teams through scrum, and the Scrum Guide gives them a fixed home at the end of every sprint. But nothing in the practice depends on sprints, story points, or having a Scrum Master in the room. Any team that finishes work in cycles can run one, and some of them get more out of it than a scrum team does, because they have no other slot set aside for talking about how the work went.

• Project teams. Run one at the end of each phase, not only at handover. A retro held after the project has shipped and the team has dispersed produces good notes and no change; one held after discovery changes the build.
• Functional and leadership teams. A monthly or quarterly retro suits teams whose work does not arrive in sprints (marketing, support, finance, an ops group). The cadence is longer, so gather the data before the session rather than in it: ask for notes a day ahead and bring a populated board.
• Incident reviews. A blameless postmortem is a retrospective with a narrower subject. The five phases hold, the prime directive matters more than usual, and the honest answer only appears once people trust that the session is about the system and not about who deployed on a Friday.
• Client and cross-company work. Two organizations in one retro needs more care about safety, not less. Anonymous input and a facilitator with no stake in the answer do most of that work.

The mechanics barely change. What changes is cadence and scope: a quarterly retro covers more ground, so timebox harder and pick one theme rather than trying to review three months in an hour. And keep the same discipline about the output. A quarterly session that produces five vague intentions is worth less than a monthly one that produces a single owned change.

Where retrospectives go wrong

Retros fail in predictable ways, and naming them is half the fix. They are predictable enough to have a literature of their own. Aino Corry’s Retrospectives Antipatterns catalogs 24 of them, and the ones below are the ones most teams meet first.

It turns into blame. The moment the session is about who caused a problem, the honest material dries up and does not come back. This is the oldest documented anti-pattern: Norm Kerth wrote the prime directive in Project Retrospectives (2001) precisely to head it off, and Corry’s catalog names it outright as “blaming and naming”. The prime directive and anonymous input exist to keep the focus on the system rather than the person.

Nothing follows through. This is the big one. A retrospective without follow-through teaches the team that nothing changes, and attendance and candor both fall. One or two actions, each with a single owner and a date, reviewed at the start of the next session. Shared ownership is no ownership. Our first-party data on retrospective follow-through puts a number on that advice: actions with both an owner and a due date complete about 90% of the time, against about two in three for those with neither.

Straight to solutions. The team grabs the first plausible fix so the meeting can end, what Corry calls the wheel of fortune, without asking why the problem happened. It feels decisive and changes little, because the fix is aimed at a symptom. The middle phases exist for a reason: group the notes, vote, and keep asking why before anything gets decided.

The same format every time. Start Stop Continue every sprint for a year turns the retro into a form to fill in. Rotate it. Esther Derby and Diana Larsen’s Agile Retrospectives pairs each of its five phases with a catalog of interchangeable activities for exactly this reason: the facilitator is meant to fit the session to the sprint, not reuse last time’s board.

Those are the ones you meet first. The deeper failure modes (a team with no power to change what is actually wrong, feedback that gets used against people later, a facilitator who is also the person appraising the room) are covered in why retrospectives fail, which is the chapter to read if your retros have gone quiet.

A retrospective without follow-through teaches the team that nothing changes. The follow-through is the whole point.

Remote retrospectives

A distributed team can run a retrospective just as well as a co-located one, and often better, because a shared online board levels the field. The mechanics shift slightly:

• Make silent, written input the default. It is already the strongest move in the room, and remotely it also solves the “everyone talks over each other on the call” problem.
• Use one shared board everyone can see and edit. Anonymity is easier online, which helps candor.
• Watch the energy. Remote sessions tire people faster, so keep it timeboxed and consider a light game to open. See online retrospective games for ideas that work over video, and the retrospective games guide for how to fold them into a session.

The five phases and the agenda above work unchanged remotely. The facilitation, not the location, is still what decides whether it lands.

Make the actions stick

Everything above is preparation for one thing: a change that actually happens. The gap between a team that improves and a team that runs retros forever without improving is not insight. Both teams see the same problems. The difference is that one of them writes down two actions with names and dates against them, and looks at that list first thing next session.

Three habits carry it:

• Two actions, not seven. A team that commits to seven changes delivers none of them, and learns that the list is decorative.
• One named owner per action. Not the team, not “we”. One person who expects to be asked about it.
• Review last time’s actions first. Before any new notes go on the board. It takes four minutes, and it is the reason the next retro gets taken seriously.

The same review habit is what keeps your team working agreements alive: reference them when one slips, and revisit the list when the team changes shape. The retrospective is the natural place for both.

Run your next retrospective in TeamRetro

You do not need a tool for any of this. A whiteboard, a timer and someone willing to hold the room will do. What a tool buys you is the parts teams reliably drop: independent brainstorming so nobody anchors on the first idea, anonymous grouping and dot-voting, a timeboxed agenda, and actions carried retro to retro so last session’s commitments are the first thing on screen next time. That is what TeamRetro’s retrospectives are built to do, and if you are still weighing up options, our guide to choosing between retrospective tools sets out what to check before you commit.

Frequently asked questions

What is a retrospective?

A retrospective is a regular session where a team looks back at the work it just finished and agrees what to change. It is usually held at the end of a sprint, a project phase, or a month, runs about an hour, and involves the people who did the work rather than their stakeholders. A good one moves through five phases (set the stage, gather data, generate insights, decide what to do, and close) and produces one or two agreed actions, each with a named owner and a date. It is not a status meeting, not a performance review, and not a place to re-plan the backlog.

What are the five phases of a retrospective?

The five phases come from Esther Derby and Diana Larsen’s Agile Retrospectives: set the stage, gather data, generate insights, decide what to do, and close. Set the stage opens the room and makes it safe to speak. Gather data gets everyone’s view of what happened onto the table. Generate insights looks for the patterns and root causes behind that data. Decide what to do turns the best insight into one or two owned actions. Close confirms the actions and checks how the session itself went. Almost every retrospective format is a different way of moving a team through these same five steps.

How long should a retrospective be?

For a typical two-week sprint, 60 minutes is a good default and enough for a focused session. Shorter teams or shorter sprints can run a tight 30 to 45 minutes; a longer look back over a quarter or a major release can justify 90 minutes or more. The length matters less than the discipline: protect the full slot, keep each phase timeboxed, and finish with agreed actions rather than running over on discussion. A retro that regularly overruns usually needs a tighter agenda, not more time.

What is the difference between a retrospective and a sprint review?

A sprint review inspects the product; a retrospective inspects the way the team works. The review comes first, usually with stakeholders in the room, and asks whether what was built is right and what should come next. The retrospective follows, with just the team, and asks how the work went and what to change about the process. Different question, different audience, different output: the review updates the backlog, the retrospective produces owned actions about how the team operates. Teams that merge the two almost always lose the retrospective half, because the product discussion expands to fill the hour. Our chapter on Sprint Review vs Sprint Retrospective goes into the detail.

Do retrospectives only work for agile teams?

No. Retrospectives reached most teams through scrum, but nothing in the practice depends on sprints, story points or a Scrum Master. Any team that finishes work in cycles can run one: a project team at the end of each phase, a marketing or support team monthly or quarterly, an engineering group after an incident. The five phases hold unchanged. What changes is cadence and scope. A quarterly session covers more ground, so gather the data before the meeting rather than in it, pick one theme instead of reviewing three months at once, and keep the same discipline about ending with a small number of owned actions.

Which retrospective format should we use?

Pick by what the team needs this week rather than by habit. Start Stop Continue is the safest default and the best first format: three columns, quick to explain, easy to turn into actions. Use Mad Sad Glad after a hard or unusual sprint when morale is the story, 4Ls after a project or a first-time piece of work, Rose Bud Thorn when the retro has drifted into a problem list and you want the positives back on the board, and Sailboat for a longer look over a release or a quarter. A simple format run well beats a clever one run badly. The one thing to avoid is running the same board every sprint for a year, which turns the session into a form to fill in.

How often should a team run a retrospective?

Once per delivery cycle is the working rule. For a two-week sprint that means every two weeks, at the end; teams on one-week sprints often run a tighter 30-minute version. Teams whose work does not arrive in sprints do better with a fixed monthly or quarterly slot than with an ad-hoc “when we need one”, which in practice means never. Less often than monthly and the material goes stale, because people are recalling work they can no longer remember clearly. More often than weekly and there is rarely enough new signal to justify the hour. Whatever the cadence, protect the slot: the first sign a team has stopped improving is that the retro becomes the meeting that gets canceled.

Why do retrospectives stop being useful?

Usually for one of three reasons, and none of them is the format. Nothing follows through: actions get agreed, nobody owns them, and the team learns that the session changes nothing. The room is not safe: people say the tidy version instead of the real thing, so the board fills with process trivia while the actual problem goes unmentioned. Or the team has no power over what is wrong: the problem is a dependency, a deadline or a decision made elsewhere, and a fortnightly meeting cannot touch it. Fix them in that order: follow through on a small number of owned actions, protect safety with anonymous input and the prime directive, and escalate the things the team cannot change instead of re-listing them every sprint. Why retrospectives fail covers each one in depth.

What is the prime directive of a retrospective?

The prime directive is a line, written by Norm Kerth, that facilitators read at the start of a retrospective to set the tone: regardless of what we discover, we understand and truly believe that everyone did the best job they could with what they knew at the time, their skills and abilities, the resources available, and the situation at hand. Its purpose is to shift the session away from blame and toward improving the system the team works in. When people trust that the room is not about fault, they raise the real problems, which is the only way a retro produces useful actions.

What’s a good agenda for a first retrospective?

Keep a first retrospective simple and safe. Use a 60-minute slot: 5 minutes to set the stage and read the prime directive, 15 minutes for everyone to add notes silently and share them, 15 minutes to group and dot-vote on what matters most, 15 minutes to agree on one or two actions with named owners and dates, and 10 minutes to close and check how it went. Choose an approachable format like Start Stop Continue or Mad Sad Glad so the team is not learning a complex framework and reflecting at the same time. The goal of a first retro is a safe, useful habit, not a perfect one.

How do you run a remote retrospective?

Run a remote retrospective on one shared online board that everyone can see and edit, and lean even harder on silent, written input first. Have each person add their notes independently, anonymously if the topic is sensitive, before any discussion, so the call does not become whoever unmutes first. Then group the notes, dot-vote, and dig into the top items together, exactly as you would in person. Keep it timeboxed because remote sessions tire people faster, and record actions with owners and dates in the same place so they carry over to next time. The five phases and a standard 60-minute agenda work unchanged over video.

Keep going

• The Scrum Master’s retrospective guide: the long-form, chapter-by-chapter companion to this overview.
• Browse retrospective templates: ready-to-run formats for your next session.
• Retrospective games guide: light activities that open a session and keep remote teams engaged.
• All TeamRetro guides: the full library, from health checks to estimation.