To run a retrospective sounds like the easiest job in agile work: get the team together, put three columns on the wall, done. Still, I know hardly any meeting that turns into a chore as quickly. After a few sprints, the same sticky notes show up again, nobody has touched last time’s action items, and at some point someone says the most dangerous sentence in the Scrum universe: “Let’s skip the retro this time, there’s nothing new anyway.”
The topic matters to me because the retrospective is the only ritual in which a team explicitly works on itself. When it goes well, everything else gets a little easier. That is why this article gives you a flow that has proven itself, five formats for different situations, an agenda you can copy and honest notes on where retros usually fail.
In short
A good retrospective follows five phases: set the stage, gather data, understand, decide, close. The key insight is that a single change you actually make is worth more than ten good ideas on sticky notes. The biggest stumbling block is a team lead who speaks too early or hands out solutions.
What you will learn in this article
- How to structure a retrospective in five phases
- A 60-minute agenda you can use right away
- Five formats and when each one fits
- How insights turn into actions that really get done
- What your role as a team lead is in the retro
What is a retrospective?
A retrospective is a regular meeting in which a team looks back at a finished period and decides what it wants to do differently from now on. It is not about the product but about collaboration: How did we work? What slowed us down? What do we want to keep?
In the Scrum Guide, the Sprint Retrospective is the last event of a sprint. There, the Scrum Team looks at individuals, interactions, processes, tools and the Definition of Done. The most helpful improvements should be tackled as soon as possible and can go straight into the Sprint Backlog of the next sprint. For a one-month sprint, the guide sets an upper limit of three hours; with shorter sprints the meeting is usually shorter. In practice, 60 to 90 minutes work well for two weeks.
By the way, you don’t need Scrum to run a retrospective. Kanban teams, platform teams or even a leadership circle can pause once a month in the same way. The difference to the Sprint Review is important: the review is about the result and stakeholder feedback, the retro is about the team itself. That is also why only the people who actually work together take part.
Why so many retros fall asleep
Before you run a retrospective next time, it pays to take an honest look at why retrospectives lose their impact. Usually it is not one reason alone but a mix.
The most common reason is simple: nothing happens. The team collects points, discusses with energy, writes down five action items, and two weeks later none of them is done. By the third time, everyone in the room has learned that the effort isn’t worth it. A second reason is routine. If you use the same three columns every time, you get the same answers every time. The third reason is more subtle and concerns the atmosphere. When people fear that a critical sentence will be used against them later, they stick to harmless topics like “The coffee machine is broken.”
A clear structure helps against all three causes. It makes sure the team first understands together and then decides, that quiet people get a say and that you end up with a few binding steps instead of many vague ones.
How to run a retrospective in five phases
In their book “Agile Retrospectives”, Esther Derby and Diana Larsen described a flow that has lasted for about twenty years. It has five phases, and each one has its own job. If you skip a phase, you usually notice later: without shared data, people argue about gut feelings; without understanding, you treat symptoms.
The five phases of a retrospective with a suggested 60-minute timing
Phase 1: Set the stage (5 minutes)
The first minutes decide whether someone is mentally still stuck in their last ticket or really present. Start by stating the goal of the retro and the timebox. Then each person gets the floor briefly, for example with the question “How was the sprint for you, in one word?”. It looks trivial, but there is a serious reason behind it: anyone who has spoken once in the first minutes finds it easier to speak again later.
Many teams read out Norm Kerth’s so-called Prime Directive at this point. It assumes that everyone did “the best job they could, given what they knew at the time”. I agree with the idea, but I don’t think reading it aloud is required. What matters more is that you as the facilitator act on it and stop any blaming in a friendly but immediate way.
Phase 2: Gather data (15 minutes)
Now it is about facts and perceptions, not yet about solutions. What happened? Which events were important? Where did things get sticky? Let everyone write silently on their own first, for at least five minutes. This silent writing is the most effective trick against the two loudest people deciding the outcome.
Feel free to add hard data to the perceptions: How many unplanned tickets came in? How often was the build red? How many pull requests waited longer than two days? Numbers don’t replace feelings, but they help turn “It all felt stressful” into a tangible topic.
Phase 3: Generate insights (15 minutes)
This phase is skipped most often, even though it makes the biggest difference. The team groups the collected points, looks for patterns and asks about causes. A short dot vote helps: each person spreads three dots across the topics they most want to talk about. Then you pick the one or two topics with the most votes.
Good questions for this phase are, for example: “When has this happened to us before?”, “What could have warned us earlier?” or “What is in our hands, and what isn’t?”. The last question is especially valuable because it keeps the team from spending 30 minutes complaining about things it cannot change.
Phase 4: Decide what to do (15 minutes)
Now the insights become experiments. I use this word on purpose because it takes the pressure off: an experiment is allowed to fail, while an “action item” sounds like a commitment for eternity. Limit yourselves to one, at most two experiments. Each one gets an owner, a concrete first step and a date when you look at it again.
Phase 5: Close (5 minutes)
Summarize the experiments out loud once more so that everyone has the same picture in mind. After that, the team gets the chance to rate the retro itself, for example with the question “How much was this hour worth to you, from 1 to 5?”. If the score drops, you know early that you should change something about the format. A short thank-you at the end sounds like politeness, but it is a signal: this time mattered.
Template: a 60-minute agenda
If you have to run a retrospective for the first time, use this agenda as a starting point. It fits a team of five to eight people and a two-week sprint. For larger teams, plan for 90 minutes instead, because collecting and discussing simply take longer.
| Minute | Phase | What happens |
|---|---|---|
| 0–5 | Set the stage | State the goal, check last time’s experiments, one-word round |
| 5–20 | Gather data | Silent writing on sticky notes, then a short walk-through and grouping |
| 20–35 | Insights | Dot vote, discuss the top topic with root-cause questions |
| 35–50 | Decide | One or two experiments with an owner and a first step |
| 50–55 | Close | Summarize, rate the retro, say thanks |
| 55–60 | Buffer | For the discussion that always takes longer than planned |
Pay attention to the first row of the table: last time’s experiments come right at the start. This way you show every time that decisions from the retro are taken seriously. If an experiment wasn’t carried out, that is not a reproach but a data point for phase 2.
Five retrospective formats
Formats are tools for individual phases, not a retro on their own. Still, if you regularly run a retrospective, you need a small selection of them. Switch them regularly, but not completely every time. A good rule of thumb: keep the flow the same and swap one or two formats per retro. You’ll find a large collection in Retromat, a free toolbox with activities for each of the five phases.
Start, Stop, Continue
The classic for phase 2: What should we start, what should we stop, what should we keep? The format is quick to explain and works well for new teams. Its weakness is repetition; after three rounds, hardly any new thoughts come up. So use it every few weeks rather than every time.
Sailboat
You draw a boat heading towards an island. The wind stands for what drives the team, the anchor for what holds it back, and the rocks for risks along the way. Your island is the goal, such as a release or a quarterly objective. The picture works surprisingly well because it makes risks visible that get lost in classic columns.
4L: Liked, Learned, Lacked, Longed for
Four columns: What did I like, what did I learn, what was missing, what did I long for? The “learned” column makes the difference because it directs attention to knowledge. Especially after a sprint with new technology, such as the team’s first work with an AI assistant, valuable points come together here.
Timeline
You draw the sprint as a time axis and mark important events, each with a mood curve above it. The timeline is worth it after turbulent periods, for example after a major outage or a tough release. It shows that people experienced the same week in completely different ways, and that is often the most important insight.
Five whys
A format for phase 3. You take the most important problem and ask “Why?” several times in a row until you reach a cause you can influence. An example: Friday’s deployment went wrong. Why? A test was missing. Why? Nobody had time for the review. Why? All reviews end up with one person. Suddenly we are no longer talking about a missing test but about shared responsibility. Make sure the question never ends with a person, but with a process.
Good experiments instead of good intentions
If I could pick only one part of this article, it would be this one. A retrospective only works if something is different afterwards. Intentions like “We communicate better” or “We write more tests” sound good and change nothing, because nobody knows what to do differently tomorrow.
A useful experiment answers four questions: What exactly are we doing? Who takes care of it? When do we start? How will we know whether it helped? So “We review faster” becomes: “Starting Monday, everyone checks the open pull requests after the daily. Lena keeps an eye on it. In the next retro we check how long PRs stayed open on average.” That is smaller, but it actually happens.
In addition, the experiment belongs where the work is visible. The Scrum Guide explicitly suggests adding improvements to the Sprint Backlog. A ticket on the board gets seen; an entry in the retro notes rarely does.
How to run a retrospective as a team lead
This is where it gets uncomfortable for managers, because when you run a retrospective as a team lead, it is harder than it looks. You have more influence in the retro than you’d like. If you speak first, you set the frame. If you answer a problem right away with “Here’s how we’ll handle it”, the discussion is over. That is why I think it makes sense not to facilitate yourself but to rotate the role within the team or invite someone from a neighboring team.
If you do facilitate yourself, three habits help. Speak last in every round. Ask questions instead of giving answers. And name topics that concern you openly: “I have the impression that my short-notice priority changes slowed you down. Is that right?” A sentence like that does more for the atmosphere than any Prime Directive. You can read more about how this trust develops in my guide to psychological safety in teams.
One last point: what is discussed in the retro stays in the team. If you take results upwards, then only the experiments and only with the team’s consent. As soon as an open sentence from the retro shows up in a status report, trust is gone for a long time.
Running a retrospective with a remote team
Remotely, the retro works just as well, sometimes even better, because digital whiteboards make silent writing and anonymous input easy. A few things still need attention. Ask for cameras to be on, at least in phases 1 and 4. Plan shorter blocks with a short break after about 45 minutes. And don’t let people write and listen at the same time; separate the two clearly: write first, then present in turn.
For teams spread across several time zones, it can help to move phase 2 forward and do it asynchronously. The board opens two days before, and in the meeting itself you start right away with grouping. I summarized which other rituals give distributed teams stability in Leading remote teams.
Common mistakes and how to avoid them
The classic is a retro without looking back at the last experiments. That sends the message that decisions have no consequences. Just as common is the list of seven action items, none of which gets done in the end. Less really is more here.
Another mistake is cutting the retro first when time is tight. It would be most valuable precisely in stressful sprints. Rather shorten it to 30 minutes with just one topic than cancel it. And finally: a retro is not a place to judge individual people. If it is about the behavior of a specific person, that belongs in a one-on-one conversation.
Finally, an underrated mistake is a retro that only looks backwards. If a big project is coming up, looking ahead can be more useful. The pre-mortem method works well for this: the team imagines the project has already failed and looks for the reasons. And if something has already broken in production, a blameless postmortem is a better fit than the regular sprint retro.
FAQ
How long does a retrospective take?
The Scrum Guide sets a maximum of three hours for a one-month sprint. For two weeks, 60 to 90 minutes are a good frame; small teams often need only 45 minutes.
Who should run a retrospective?
In Scrum, the Scrum Master often does it. Rotating the role within the team or inviting someone from another team also works well. The team lead should rather not facilitate, because they can easily steer the discussion without meaning to.
What is the difference between a Sprint Review and a retrospective?
In the review, the team inspects the sprint’s result together with stakeholders. In the retrospective, the team only looks at itself: at collaboration, processes and tools.
What if nobody says anything in the retro?
Start with silent individual work and anonymous input, for example on a digital whiteboard. If it stays quiet anyway, that in itself is a sign of missing trust, and it is worth an honest conversation.
Your next step
The next time you get to run a retrospective, focus on just one thing: put last time’s experiments at the very start of the agenda and limit the outcome to a single new experiment with a name and a first step. It takes no preparation and, in my experience, noticeably changes how seriously the team takes the retro.
I’m curious: which retro format has moved your team the most, and which one did you drop again? Let me know in the comments.
Sources
- Ken Schwaber, Jeff Sutherland: The Scrum Guide (November 2020), section Sprint Retrospective
- Esther Derby, Diana Larsen: Agile Retrospectives. Making Good Teams Great (Pragmatic Bookshelf, 2006)
- Retrospective Wiki: The Prime Directive (Norm Kerth, Project Retrospectives)
- Retromat: What is a retrospective? (the five phases)
This post was created with AI assistance.
👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)