What Is a Sprint Retrospective in Agile? A Practical Guide for 2026

A Sprint Retrospective is the final event of a Sprint, where the Scrum Team examines how it worked and agrees concrete improvements for the next Sprint. It looks at process, collaboration and tools rather than the product itself, and it is timeboxed to a maximum of three hours for a one month Sprint.

Key Highlights

• The Sprint Retrospective closes every Sprint and is attended by the whole Scrum Team: Developers, Product Owner and Scrum Master.
• The Scrum Guide timeboxes it at three hours maximum for a one month Sprint. Most teams on two week Sprints run it in 60 to 90 minutes.
• It examines how the team worked, not what it built. Inspecting the product is the job of the Sprint Review.
• The most common failure is not a bad format. It is that agreed actions never get implemented, so the same issues resurface Sprint after Sprint.
• One improvement actually delivered beats five discussed and forgotten. Teams that limit themselves to one or two owned actions per Sprint change faster than teams that generate long lists.
• Rotating format prevents fatigue, but format is a smaller lever than follow through and psychological safety.

What Is a Sprint Retrospective?

The Sprint Retrospective is where a Scrum Team stops building and looks at itself.

It is the concluding event of the Sprint, held after the Sprint Reviewand before the next Sprint begins. The team inspects how the last Sprint went in terms of individuals, interactions, processes, tools and its Definition of Done, then identifies what to change.

The output is not a report. It is a small number of specific improvements the team commits to making in the next Sprint.

That distinction matters because it separates a retrospective from a general team discussion. A conversation where everyone airs frustrations and nothing is decided is not a retrospective. It is a vent. The event only earns its place when something concrete changes as a result.

The Retrospective sits alongside the other five events of Scrum, and it is the one most often treated as optional when a team is under pressure. That instinct is backwards. The Sprints where you feel you cannot spare 90 minutes are usually the Sprints that most need the conversation.

Retrospective vs Review: Two Different Events

These get confused constantly, including by experienced teams.

The simplest way to hold them apart is the subject. The Review inspects the product. The Retrospective inspects the process.

Running them as one meeting is a common shortcut and it reliably damages both. Stakeholders are present in the Review, and teams will not speak honestly about internal friction in front of them. If you have merged the two, separating them is usually the single highest impact change you can make. It is worth understanding the full comparison between the Review and the Retrospective before you restructure your cadence.

Who Attends and Who Runs It

The whole Scrum Team attends: the Developers, the Product Owner and the Scrum Master.

The Product Owner's presence is sometimes debated. They belong there. They are part of the Scrum Team, and much of what slows delivery involves the flow of work between the Product Owner and the Developers. Excluding them removes half the conversation. TheProduct Owner's role in the Retrospective is to participate as a team member, not to evaluate performance.

Managers and stakeholders do not attend. This is not secrecy. It is that people speak differently when someone who influences their appraisal is in the room, and the event depends entirely on candour.

The Scrum Master usually facilitates, though not always. Rotating facilitation among team members is a genuinely good practice once the team is mature. It spreads ownership and stops the event becoming the Scrum Master's meeting rather than the team's. Strongfacilitation technique matters more here than in any other Scrum event.

If you are moving into a Scrum Master role, facilitating retrospectives well is one of the skills that separates competent practitioners from people who simply run meetings. Our CSM Certification Trainingcovers facilitation with accredited Scrum Alliance trainers who have run these sessions with real teams.

How Long Should a Retrospective Be?

The Scrum Guide sets a maximum of three hours for a one month Sprint, and shorter proportionally for shorter Sprints.

These are maximums, not targets. A focused 50-minute retrospective that produces one owned action beats a rambling two-hour session that produces a list nobody reads.

That said, cutting it to 15 minutes because the Review overran is a false economy. If the event is consistently getting squeezed, the problem is the schedule, not the retrospective.

The Five Phases of a Retrospective

Most effective retrospectives follow the same underlying structure, regardless of which format sits on top. It comes from Esther Derby and Diana Larsen's work on Agile retrospectives and has held up well.

Set the stage: Open the session, remind everyone of the purpose, and get every person to say something early. This matters more than it sounds. People who speak in the first few minutes are far more likely to contribute later. A single question answered around the group is enough.

Gather data: Collect what actually happened. Facts, events, metrics, feelings. The aim is a shared picture of the Sprint before anyone starts explaining it. Silent written input works better than open discussion here, because it prevents the loudest voice from framing the Sprint for everyone else.

Generate insights: Move from what happened to why. This is where the team looks for patterns and root causes rather than symptoms. Techniques like asking why repeatedly, or grouping related observations, do the work.

Decide what to do: Choose improvements. Few, specific, and owned by a named person. This phase is where most retrospectives quietly fail, and the next section deals with it properly.

Close the retrospective: Summarise the decisions, confirm the owners, and briefly check how the session itself went. Closing properly signals that the meeting produced something, which is what keeps people engaged next time.

Teams that skip straight to generating ideas without gathering data tend to relitigate opinions. Teams that gather data but never close tend to lose the actions.

Why Most Retrospectives Fail

This is the part the internet mostly skips. There is no shortage of articles listing thirty different retrospective formats. Format is rarely the real problem.

The dominant complaint from practitioners is remarkably consistent: the same issues come up Sprint after Sprint, actions get agreed, and nothing changes. Once a team has experienced that a few times, engagement collapses. People stop raising real problems because raising them has never led anywhere.

Here is what actually causes it.

Too many actions: A team generates eight improvements, owns none of them properly, and delivers zero. Capacity for change is small. One or two real improvements per Sprint is a healthy rate.

No named owner: An action owned by the team is owned by nobody. Every improvement needs one person accountable for it happening, even if the work is shared.

Actions with no place to live: If improvements are captured in a retrospective tool nobody opens again, they evaporate. Put them where the team already looks, which for most teams means the Sprint Backlog.

No follow-up at the start of the next retrospective: The first item on the agenda should be what happened to last Sprint's actions. This single habit changes behaviour faster than anything else, because it makes follow-through visible.

Problems outside the team's control: Some issues genuinely cannot be fixed by the team. Repeatedly raising them without escalation produces learned helplessness. The Scrum Master's job is to take those away as impediments rather than let them recur in every session.

No psychological safety: If people cannot say what is actually wrong, the retrospective discusses only safe topics. Nothing that matters gets surfaced. This is usually a symptom of managers attending, of blame following honesty, or of a team that has not yet built trust.

Same format for a year: Fatigue is real, but it is a secondary problem. Rotating format on top of a broken follow-through loop just produces more engaging meetings that still change nothing.

The uncomfortable truth is that a plain retrospective with disciplined follow-through outperforms a beautifully facilitated one where the actions disappear.

Retrospective Formats Worth Using

Format gives the conversation structure and stops every session sounding identical. Here are the ones that earn their place, and when to reach for each.

Rotate every few Sprints rather than every Sprint. Constant novelty has its own cost, since the team spends time learning the format instead of using it.

One technique is worth more than any format: silent writing followed by dot voting. Everyone writes observations independently for a few minutes, the group clusters them, then votes on what to discuss. It fixes the most common facilitation problem, which is one person consuming most of the airtime while quieter members contribute nothing.

Running Retrospectives for Remote and Distributed Teams

Most teams now run at least some retrospectives remotely, and the format needs adjusting.

Use a shared canvas where everyone types their own observations rather than one person transcribing. Transcription creates a filter and slows everything down.

Rotate facilitation, because remote sessions drift more easily and a fresh facilitator resets the energy.

Make cameras a choice rather than a requirement. Mandating them adds pressure without improving the conversation.

For teams spread across wide time zones, split the session. Gather data asynchronously in advance, then hold a shorter synchronous session to generate insights and decide actions. Trying to force a full retrospective into a 45 minute overlap window at the edge of someone's working day produces a poor conversation.

Silent writing works better remotely than in person, because everyone types at once and nobody waits for a turn.

How to Make Improvements Actually Stick

If you change only one thing after reading this, make it this section.

Limit yourself to one or two improvements per Sprint. Fewer, finished.

Give each one a named owner and a definition of what done looks like. Improve communication is not an action. Add a fifteen minute mid Sprint check against the Sprint Goal, owned by Priya, is an action.

Put the improvement in the Sprint Backlog alongside the product work. Improvements that live outside the Sprint Backlog compete with delivery work and lose every time.

Open the next retrospective by reviewing what happened to the previous actions. Not as a blame exercise, simply as a fact. When a team sees its own follow through rate honestly, behaviour shifts.

Escalate what the team cannot fix. If a dependency on another team is blocking every Sprint, the Scrum Master takes that outside the team as an impediment. Letting it appear in every retrospective teaches the team that raising problems is pointless.

Track your follow through rate over time. The proportion of agreed actions actually completed is a better health measure for a team than velocity, because it tells you whether the team is capable of improving itself.

Unresolved process problems compound in the same way technical debt does. Each Sprint they persist, they cost a little more.

A Worked Example: Turning a Recurring Complaint Into a Fixed Problem

Abstract advice about follow through is easy to nod at and hard to apply. Here is what it looks like in practice.

A team raises the same issue three Sprints running: testing always gets crushed into the final two days, and items are declared done without being properly verified.

In the failing version, this gets written on a sticky note, the team agrees they should test earlier, everyone nods, and nothing changes. It appears again next Sprint.

In the working version, the team pushes past the symptom. Testing is late because items are not picked up until mid Sprint, and items are not picked up until mid Sprint because three people start three separate items on day one rather than finishing one together. The root cause is not testing discipline. It is work in progress.

The team chooses one improvement. Limit work in progress to two items at a time for the next Sprint. Anand owns it. Success looks like no more than two items in progress on the board at any point, checked at each Daily Scrum.

That improvement goes into the Sprint Backlog as a visible item, not into a retrospective tool.

The next retrospective opens with it. Did work in progress stay at two? Mostly, it slipped twice. Did testing move earlier? Yes, three items reached done by day six compared with zero the previous Sprint. The team keeps the limit and adds one refinement.

Two Sprints later, nobody mentions late testing, because it has stopped happening.

Three things made the difference. The team looked for a cause instead of restating the symptom. They chose one change rather than five. And they checked the result at the start of the next session, which is what turned an intention into a habit.

Notice also that the fix had nothing to do with the retrospective format. It came from the discipline applied afterwards. Reviewing the Definition of Done is often part of this conversation too, since a loose definition is what allows unverified work to be called finished in the first place.

How Retrospectives Should Change as a Team Matures

A retrospective that suits a brand new team is wrong for a team that has been together two years, and vice versa.

A new team needs structure. Formats like Start, Stop, Continue work because they are unambiguous and require no interpretation. Sessions focus on basic mechanics: are the events happening, is the board accurate, does everyone understand theSprint Goal. The Scrum Master facilitates every session and does a lot of the work holding the shape.

A developing team starts finding patterns rather than incidents. Conversation moves from what happened this Sprint to what keeps happening. Formats rotate. Facilitation begins to pass around the team. Improvements start targeting flow and quality rather than process compliance.

A mature team runs retrospectives that would look strange to an outsider. They may spend the whole session on one topic. They may skip formats entirely and simply talk, because trust is high enough that structure is no longer needed to get honesty. Facilitation rotates naturally. Improvements are often experiments with an explicit hypothesis and a measure.

The mistake is applying mature team practice to a new team, or continuing to run a rigid format with a team that outgrew it two years ago. If your retrospectives feel mechanical, the format may simply no longer fit where the team is. Recognising that shift is part of the coaching side of the role, and it is covered in depth in CSM Certification Training alongside the framework itself.

Building the Psychological Safety a Retrospective Needs

Every technique above assumes people will say what they actually think. Without that, a retrospective is a scripted exercise.

Psychological safety here means a specific thing: a team member can name a problem, admit a mistake or disagree with a senior colleague without expecting a cost. It is not about being comfortable or avoiding conflict. Safe teams argue more, not less. They just argue about the work.

A few things build it, and a few destroy it quickly.

Keep managers out of the room. This is the fastest structural fix available. However good the relationship, people edit themselves in front of someone who influences their pay.

Separate the problem from the person. The team examines what happened in the system, not who is at fault. Norm Kerth's retrospective prime directive captures this well, the principle being that everyone did the best job they could with what they knew and the resources they had at the time. Opening with that framing is a small ritual that resets the tone.

Have the most senior person in the room speak about their own mistakes first. Nothing signals safety faster, and nothing signals its absence faster than a senior person who only ever critiques others.

Act on what gets raised. Safety is not built by inviting honesty, it is built by responding to it well. A team that raises something difficult and sees it addressed will raise the next thing. A team that raises something difficult and watches it disappear will not.

Never let anything from a retrospective be used in a performance conversation. Once that happens, even once, the event is finished as a place for honesty and it is very hard to recover.

What a Good Retrospective Looks Like

A healthy retrospective has a recognizable feel.

Everyone speaks within the first five minutes. Problems are described plainly without anyone becoming defensive. The team spends more time on why something happened than on what happened. Disagreement occurs and is handled. Two or three specific improvements are chosen, each with an owner. The session ends on time. Someone mentions an improvement from last Sprint that is now simply how the team works.

Compare that with the failing version. Two people talk, the rest wait it out. The same three complaints appear as they did last Sprint. Actions are vague and unowned. The session overruns and ends without decisions, or ends early because nobody has anything left to say.

Recognizing which one you are in is the first step. The improvements above are what move a team from the second to the first, and it usually takes several Sprints rather than one.

This kind of diagnosis is core Scrum Master work. It draws on facilitation, coaching and conflict handling rather than process knowledge, which is why the Scrum Master skill set extends well beyond knowing the framework.

How to Measure Retrospective Health

Teams rarely measure this event, which is part of why it decays unnoticed. Four simple indicators tell you most of what you need.

Action completion rate: Of the improvements agreed in the last five retrospectives, how many were actually finished? Below half means the event is producing intentions rather than change, and follow through is the thing to fix first.

Repeat topic rate: How often does the same issue reappear across Sprints? A recurring topic is either not being acted on or sits outside the team's control. Both need a response, and they need different responses.

Participation spread: Roughly what share of the talking is done by the quietest half of the team? If a small group dominates every session, switch to silent writing and voting before changing anything else.

Time to raise a hard thing: This one is subjective but telling. How long into a session before someone says something genuinely uncomfortable? In a healthy team it happens early. In an unsafe team it never happens at all.

Review these every few months rather than every Sprint. The point is to notice a slow decline, and slow declines are invisible Sprint to Sprint.

Frequently Asked Questions

1. What is the purpose of a Sprint Retrospective?

To inspect how the team worked during the Sprint and agree specific improvements for the next one. It examines process, collaboration, tools and the Definition of Done rather than the product itself.

2. How long should a Sprint Retrospective last?

The Scrum Guide caps it at three hours for a one month Sprint, scaled down for shorter Sprints. Teams on two week Sprints typically use 60 to 90 minutes.

3. Who attends the Sprint Retrospective?

The whole Scrum Team: Developers, Product Owner and Scrum Master. Managers and external stakeholders do not attend, because their presence suppresses honest discussion.

4. What is the difference between a Sprint Review and a Sprint Retrospective?

The Review inspects the product with stakeholders and adapts the Product Backlog. The Retrospective inspects how the team works and produces process improvements. Different subject, different attendees, different output.

5. Is the Sprint Retrospective mandatory in Scrum?

Yes. It is one of the prescribed Scrum events and happens at the end of every Sprint. Skipping it removes the mechanism through which the team improves.

6. What do you do when the same problems come up every retrospective?

Check two things. First, whether agreed actions are being implemented, which is usually the cause. Second, whether the problem is actually within the team's control. If it is not, the Scrum Master should escalate it as an impediment rather than let it recur.

7. Can the Product Owner attend the retrospective?

Yes, and they should. The Product Owner is part of the Scrum Team, and the flow of work between them and the Developers is often exactly what needs examining.

8. How many action items should come out of a retrospective?

One or two that get implemented is better than eight that do not. Change capacity is limited, and long lists dilute accountability.

Closing Thoughts

The Sprint Retrospective is the event that makes Scrum a learning system rather than a delivery routine. Without it, a team repeats the same Sprint indefinitely, including the parts that do not work.

It is also the easiest event to hollow out. Nobody notices immediately when a retrospective stops producing change. The meeting still happens, people still attend, and the decline is invisible until someone points out that the same issue has appeared for six Sprints running.

The teams that get real value from retrospectives are rarely the ones with the most creative formats. They are the ones that pick one or two improvements, name an owner, put the work where it will actually be seen, and check what happened at the start of the next session.

If you want to build these facilitation skills properly, CSM Certification Training from an accredited provider gives you both the framework and the practical coaching techniques. You can also test your understanding first with our free CSM practice test, or compare the available Scrum Master certification routes before deciding which fits your career.