How to Run a Sprint Retrospective That Leads to Real Change

The Sprint Retrospective is where a Scrum Team improves how it works. Done well, it can be the most valuable part of the Sprint: a regular, protected moment to step back, look honestly at what happened and decide what to change. Done badly, it becomes a routine complaint session that nobody looks forward to and nothing changes as a result. This guide explains what the Scrum Guide says about the Retrospective, gives you a simple structure you can use every Sprint, and shares practical formats and facilitation tips for making improvements actually stick.

Key takeaways

• The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
• It is the last event of the Sprint and is timeboxed to three hours for a one-month Sprint.
• The whole Scrum Team takes part, including the Product Owner and the Scrum Master.
• A simple five-step structure works for almost any team: set the stage, gather data, generate insights, decide what to do, close.
• One or two concrete, owned actions are worth more than a long list nobody follows up.

What is a Sprint Retrospective?

The Sprint Retrospective is one of the five Scrum events defined in the Scrum Guide. According to the guide, its purpose is to plan ways to increase quality and effectiveness.

During the Retrospective, the Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. The team discusses what went well during the Sprint, what problems it encountered, and how those problems were or were not solved. The Scrum Guide adds that assumptions that led the team astray are identified and their origins explored.

The team then identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible, and they may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective concludes the Sprint.

For how the Retrospective fits with the other events, see the five Scrum events explained.

Why the Retrospective matters

Scrum is built on empiricism: inspecting what actually happens and adapting based on it. Most Scrum events apply that idea to the product. The Retrospective applies it to the team itself. Without it, a team can deliver Sprint after Sprint while repeating the same problems: the same kind of defect, the same late dependency, the same unclear items. The Retrospective is the team's built-in mechanism for noticing those patterns and changing them.

It also matters for the team's health. A regular, safe space to raise concerns means small frustrations get addressed before they turn into bigger conflicts.

Who attends and who facilitates?

The whole Scrum Team takes part: the Developers, the Product Owner and the Scrum Master. The Product Owner is a member of the Scrum Team, so their perspective on how the team works together belongs in the conversation.

The Scrum Master is accountable for making sure all Scrum events take place and are positive, productive and kept within their timebox. In practice, the Scrum Master often facilitates the Retrospective, especially for newer teams. But the outcome belongs to the team. Some mature teams rotate facilitation between members, which builds shared ownership. Read what does a Scrum Master do? for more on the role.

The Retrospective is usually kept to the Scrum Team, because people speak more openly without outside observers. If the team wants to involve someone else for a specific topic, it can agree that together.

Sprint Review vs Sprint Retrospective

	Sprint Review	Sprint Retrospective
Focus	The product: what was done and what to do next	The team: how it worked and how to improve
Who takes part	Scrum Team and key stakeholders	Scrum Team
Main outcome	An adapted Product Backlog	Improvements to how the team works
Maximum length (one-month Sprint)	4 hours	3 hours
When	Second-to-last event of the Sprint	Last event of the Sprint

How long should a Retrospective be?

The Scrum Guide sets a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The timebox is a maximum, not a target. What matters is that the team has enough time to go beyond surface complaints and agree meaningful changes. Many teams with two-week Sprints find that an hour to ninety minutes works well, but the right length depends on the team and what it needs to discuss.

Before the Retrospective: preparation

A good Retrospective often depends on a little preparation. Before the event, the facilitator can:

• Review last time's actions. Check which were completed, and be ready to discuss those that were not.
• Gather a few facts. For example, how many items reached the Definition of Done, how many were carried over, and which impediments came up.
• Choose a format. Pick one that suits the Sprint. A difficult Sprint may need a format that leaves room for feelings; a smooth one might suit a forward-looking format.
• Prepare the space. A room with a wall and sticky notes, or an online whiteboard that everyone can use.
• Protect the time. Make sure the Retrospective is in everyone's calendar and not squeezed out by other work.

A simple five-step structure

Esther Derby and Diana Larsen describe a five-stage structure for retrospectives in their book Agile Retrospectives: Making Good Teams Great. It works for almost any team and any format.

1. Set the stage

Remind everyone of the Retrospective's purpose and the timebox. Help people feel safe to speak honestly. A quick check-in works well, such as asking everyone to describe the Sprint in one word. Some teams use a short, anonymous check of how comfortable people feel speaking openly; if comfort is low, that becomes the first thing to address.

2. Gather data

Build a shared picture of the Sprint. Memories differ, so it helps to put facts on the wall: key events, completed and carried-over items, impediments, and moments that felt good or bad. A timeline of the Sprint is a simple, effective way to do this.

3. Generate insights

Now look for patterns and causes, not just symptoms. Grouping related notes together helps themes emerge. Asking "why?" several times about a problem, sometimes called the five whys, often reveals a deeper cause. If there are many themes, the team can use dot voting to decide which to focus on.

4. Decide what to do

Agree one or two concrete improvements. Each should be specific, have an owner and be small enough to start in the next Sprint. Following the Scrum Guide, the most impactful improvement can be added to the Sprint Backlog for the next Sprint, so it gets the same attention as other work.

5. Close

Summarise the actions and who owns them. Thank people for their honesty. Many teams end with a quick "retrospective of the retrospective": how useful was this session, and what could make the next one better?

Popular Retrospective formats

Changing the format every few Sprints keeps the conversation fresh and helps the team look at its work from different angles. These are some of the most widely used:

• Start, Stop, Continue: What should the team start doing, stop doing and keep doing? Simple and quick, good for new teams.
• Mad, Sad, Glad: Useful after an emotionally difficult Sprint, when feelings need to be aired before problem-solving.
• 4Ls: What the team Liked, Learned, Lacked and Longed for. Good for balancing positives and gaps.
• Sailboat: The wind pushing the team forward, the anchors holding it back, and the rocks ahead. Helps teams think about risks as well as past problems.
• Starfish: What to keep doing, do more of, do less of, stop doing and start doing. A more nuanced version of Start, Stop, Continue.
• Timeline: The team maps the Sprint day by day and marks highs and lows. Useful for longer Sprints or when memories differ.
• Lean Coffee: Participants propose topics, vote on them and discuss them in order, with a short time limit on each. Good for experienced teams who know what they want to talk about.

An example 60-minute agenda

As an illustration only, a team with two-week Sprints might run a one-hour Retrospective like this:

Time	Step	Activity
0 to 5 minutes	Set the stage	Purpose, one-word check-in, review of last Sprint's actions
5 to 20 minutes	Gather data	Everyone writes notes silently, then places them on the board
20 to 40 minutes	Generate insights	Group notes into themes, dot vote, explore the top theme
40 to 55 minutes	Decide what to do	Agree one or two actions with owners; add the key one to the next Sprint Backlog
55 to 60 minutes	Close	Summary, appreciation, quick feedback on the session

Running Retrospectives with remote teams

• Use an online whiteboard that everyone can write on at the same time.
• Start with silent writing. A few minutes of individual writing before discussion gives quieter people an equal voice.
• Use rounds. Ask each person in turn, so the loudest voices do not dominate.
• Keep energy up. Shorter segments and a clear agenda matter more online than in a room.
• Save the board. A shared record makes it easy to review actions next time.

How to make improvements stick

• Pick one or two actions, not ten. A short list gets done; a long one gets forgotten.
• Make each action specific. "Improve testing" is vague. "Add automated tests for the payment module this Sprint" is actionable.
• Give each action an owner. Someone needs to be responsible for moving it forward, even if the whole team helps.
• Put actions where the team will see them. Adding the most important one to the Sprint Backlog, as the Scrum Guide allows, keeps it visible.
• Start each Retrospective by reviewing the last one's actions. This single habit is what turns discussion into change.
• Treat improvements as experiments. If a change does not help, the team can drop it and try something else.

Facilitation tips for Scrum Masters

• Stay neutral. The facilitator's job is to help the team think, not to steer it towards a conclusion.
• Protect equal voice. Use silent writing, rounds and anonymous input where needed.
• Focus on the system, not individuals. Ask "what made this happen?" rather than "who did this?"
• Use a parking lot. If an important topic cannot be covered in time, note it and agree when it will be discussed.
• Keep to the timebox. Ending on time builds trust that the Retrospective is worth attending.
• Vary your approach. The same format every Sprint leads to the same answers.

Common pitfalls and how to fix them

• Blaming individuals. Refocus on processes and conditions. People rarely fail in isolation.
• One or two voices dominating. Switch to silent writing and structured rounds.
• Skipping the Retrospective because the team is busy. This is when it is needed most. Even a short Retrospective is better than none.
• Agreeing actions the team cannot influence. If the problem sits outside the team, the action can be to raise it with the right person, often through the Scrum Master.
• Actions that are never followed up. Start every Retrospective by reviewing previous actions.
• "Nothing to improve". Try a different format, bring data on carried-over work or defects, or ask what would make the next Sprint 10% better.

Signs of a healthy Retrospective

• Everyone speaks, not just a few people
• The team discusses real problems openly, without blame
• Actions from previous Retrospectives are completed and their effect discussed
• The team can point to specific changes that came from its Retrospectives
• People see the event as useful rather than a ritual

Retrospective ideas for specific situations

After a Sprint where the team missed its Sprint Goal

Emotions may run high, so start by acknowledging that the Sprint was difficult. A timeline works well here: it lets the team see exactly when things started to go wrong, rather than arguing from memory. Focus on what the team can learn and change, such as how it planned, how it handled unexpected work, or whether the Sprint Goal was clear enough in the first place.

With a brand-new team

New teams often do not yet feel safe enough to raise problems. Keep the format simple, such as Start, Stop, Continue, and spend more time on setting the stage. Agreeing a few working agreements, for example how the team will make decisions or handle disagreement, can be a useful first action.

After a major release

A release is a good moment to look back over a longer period than one Sprint. A timeline covering the whole release helps the team see which practices helped and which slowed it down, and to celebrate what went well.

When there is tension in the team

Conflict is normal, but a Retrospective is not the place to single people out. Focus on how the team works together: how decisions are made, how work is shared and how people communicate. If a conflict is personal and serious, the Scrum Master may need to address it separately before bringing the team together.

With a long-running team that feels stuck

If the Retrospective has become predictable, change something significant: a new format, a different location, a guest facilitator from another team, or a focus on a single theme such as quality or collaboration with stakeholders. A fresh angle often brings new insight.

Retrospectives beyond one team

Some impediments cannot be solved inside a single Scrum Team. When several teams work on the same product, many organisations hold occasional joint Retrospectives with members from each team, to improve how the teams work together. The Scrum Guide does not prescribe this, but it is a common practice. Organisational problems raised in a team's Retrospective, such as slow approvals or unclear priorities between departments, are part of the Scrum Master's work with the wider organisation. Scrum Leader Plus covers leading improvement across several teams.

How to tell if your Retrospectives are working

A Retrospective is working when it leads to change the team can see. A few simple checks help:

• Keep a short list of the actions agreed in each Retrospective and whether they were completed.
• Every few Sprints, ask the team which changes actually made a difference.
• Look at whether recurring problems, such as carried-over work or late dependencies, are becoming less frequent.
• Ask for honest feedback on the Retrospective itself at the end of each session.

If the same problems keep appearing, that is valuable information in itself. It may mean the actions are too vague, the causes lie outside the team, or the team does not yet feel safe to discuss the real issue.

Using data and AI in Retrospectives

For a detailed guide, see using AI in Sprint Retrospectives.

Data can make Retrospectives more objective: carried-over work, recurring impediments or patterns in defects often tell a story that memory misses. AI tools can help summarise Sprint data or group notes into themes before the session. They do not replace the honest conversation that makes a Retrospective work. Scrum Master AI Plus covers AI-assisted Retrospectives in more detail.

Build your facilitation skills

Facilitating good Retrospectives is a core Scrum Master skill. Scrum Master Plus (Associate) includes 16 hours of training and an online exam on ExamVault by CertExpert with three attempts included. The certificate and digital badge are valid for two years. For the full picture of the role, read our complete Scrum Master guide.