How to Run a Great Sprint Retrospective

The sprint retrospective has a simple definition in the Scrum Guide: the team inspects how the last sprint went with regards to people, relationships, process, and tools. They identify the most helpful changes and create a plan to implement them. That is it. No blame, no performance reviews, no management reports.

In practice, retrospectives are often misused. They become complaint sessions where the same problems get raised every sprint but nothing changes. Or they become performance reviews where the team reports to management. Or they get cancelled whenever the team is under pressure — which is precisely when they are most needed.

A genuinely effective retrospective does two things: it surfaces the truth about how the team is working, and it produces specific, actionable commitments to improve. Without both, it is just a meeting. The goal of this guide is to show you how to achieve both, consistently, even with teams that are skeptical of the process.

Start / Stop / Continue is the simplest and most widely used format. Each team member contributes to three lists: things we should start doing, things we should stop doing, and things we are doing well and should continue. It is intuitive, quick to explain to new participants, and produces actionable items directly. The risk is that it becomes predictable and teams stop bringing fresh observations after a few sprints.

4Ls (Liked, Learned, Lacked, Longed for) pushes the team to think in multiple dimensions. "Liked" and "Learned" surface positives in different ways (what felt good vs. what was valuable). "Lacked" identifies missing resources, skills, or information. "Longed for" surfaces desires that might not be immediately actionable but are worth naming. This format works well for teams that have outgrown Start/Stop/Continue and need more nuance.

Mad / Sad / Glad is emotion-forward. Team members share things that made them frustrated (mad), things that were disappointing or concerning (sad), and things that went well (glad). The emotional framing can unlock conversations that purely process-focused formats miss — team dynamics issues, morale problems, and interpersonal friction often surface more readily here. Use it when you suspect there are unspoken team dynamics problems.

Sailboat uses a visual metaphor: the sailboat moving toward an island (the goal). Wind represents what is propelling the team forward. Anchors represent what is slowing them down. Rocks below the waterline represent risks. The island represents what the team is trying to achieve. This format works especially well for newer teams that benefit from the visual structure, and for retrospectives focused on a longer time horizon than a single sprint.

The most important facilitation principle for retrospectives: the facilitator should not have opinions. If the scrum master has strong feelings about what went wrong last sprint, they need to set those aside and focus on drawing out the team's perspective. A facilitator who advocates for their own view suppresses the voices of team members who disagree.

Start with silent individual brainstorming before any group discussion. Give everyone five minutes to write their own observations on sticky notes or in the tool, privately. This equalizes participation — introverts get their thoughts recorded before the extroverts dominate, and nobody anchors on the first thing someone else says.

After individual brainstorming, do a read-out and group similar items. This grouping phase often reveals themes that no individual observation shows: multiple people raising similar but slightly different points about communication, or about deployment, usually indicates a systemic issue rather than individual incidents.

The discussion of grouped themes should be time-boxed. Give each major theme five minutes. If the team is still generating productive insights at the five-minute mark, extend. If the discussion is spinning — people repeating points already made, escalating emotion without new information — close it and move to action items. Not every problem raised in a retrospective needs to be solved in that retrospective.

Remote retrospectives require more deliberate structure than in-person ones. The casual side conversations that happen around a physical sticky-note wall — "oh, you felt that too? I thought it was just me" — simply do not happen over video. You have to create the conditions for those conversations explicitly.

Use a digital whiteboard tool (Miro, FigJam, Retrium, or similar) rather than trying to run a retrospective over shared documents or chat. The visual grouping and movement of ideas is important to the process and does not translate well to linear chat threads.

Keep cameras on throughout. This is one meeting where the visual cues of body language and facial expression genuinely matter. Someone's reluctance to share or their visible frustration when a topic is raised is information the facilitator needs.

Add a brief personal check-in at the start. Two minutes where each person shares their current state — one word or one sentence about how they are feeling coming into the session. This human grounding helps people shift from task mode to reflection mode, and it surfaces if someone is having a rough day in a way that should inform how the facilitator handles discussions that might be sensitive.

The graveyard of retrospectives is full of good ideas that never got implemented. The most common reason: action items were vague ("improve communication"), unowned (no specific person responsible), or too many to actually do (ten action items from one retrospective).

Apply three rules to every retrospective action item. First, it must be specific enough that the team can confirm next sprint whether it was done or not. "Improve communication" fails this test. "Hold a five-minute post-merge sync every Tuesday to catch integration issues early" passes it. Second, it must have a single owner — one person who is accountable for making it happen, even if others contribute. Third, there should be no more than two or three action items per retrospective. Fewer, better-implemented improvements beat a long list of abandoned intentions every time.

At the start of every retrospective, before generating new items, review the previous sprint's action items. Were they done? If not, why? This accountability loop is what makes retrospectives compound over time — each sprint builds on the improvements of the last rather than resetting to zero.

How do you know if your retrospectives are working? Most teams do not measure this at all, which is ironic given that retrospectives are supposed to drive improvement. Here are three practical signals to watch.

Action item completion rate. What percentage of retrospective action items get completed before the next retrospective? Healthy teams complete 70 to 80 percent. Below 50 percent indicates either the items are too vague, the team has too many, or there is no accountability mechanism. Track this simply: note it at the start of each retro when you review the previous sprint's items.

Sentiment shift. Are the themes raised in retrospectives improving over time? If the team has raised "unclear requirements" for five consecutive sprints, something is systemically wrong — either the retrospective actions are not reaching the root cause, or there is an external constraint preventing improvement. Keeping a log of retrospective themes allows you to track whether the same problems keep recurring.

Participation quality. Are all team members contributing, or are two or three voices dominating? Is the conversation getting more honest over time, or are people playing it safe? Participation quality is harder to measure but easy to observe. Vary your formats periodically to keep engagement high and to make it easier for different people to contribute in the way that works best for them.

Every experienced scrum master has a story about the retrospective that changed everything. The one where someone finally said the thing that everyone had been thinking but nobody had said. The one where the team realized the problem they thought was about process was actually about relationships. The one where a single action item — genuinely implemented — broke a cycle of dysfunction that had persisted for months.

These breakthroughs are not accidents. They happen in teams that have built the psychological safety to be honest, the facilitation skill to hold space for difficult conversations, and the discipline to follow through on what they commit to. None of these qualities appear overnight. They are built through consistent, well-run retrospectives over many sprints.

Start simple. Pick a format, run it consistently, review action items every sprint. Do not try to optimize the format before you have run it five times. The most important property of a retrospective is that it happens — reliably, at the end of every sprint, without exception. Compound improvement is the most powerful force available to a software team, and the sprint retrospective is how you activate it.