Sprint Retrospective in Scrum

The Sprint Retrospective helps the Scrum Team inspect how it worked and choose improvements for the next sprint.

Every Scrum Team has room to improve. The retrospective gives the Scrum Team a regular, focused opportunity to discuss what helped, what got in the way, and what changes would make future sprints better.

A good retrospective leads to action. The Scrum Team does not need a long list of improvements. It needs honest conversation and follow-through on a few things that matter.

Who This Page Is For

This page is for Scrum Teams that want retrospectives to lead to real improvement.

It is especially useful for:

Scrum Masters facilitating retrospectives
Developers who want recurring problems to be addressed
Product Owners participating in team improvement
Teams that keep discussing the same issues without change
Leaders trying to understand how Scrum Teams improve their way of working

What This Page Covers

This page explains the purpose of the Sprint Retrospective, who attends, when it happens, how to run one, and how to make improvements visible in the next sprint.

It also covers common retrospective problems, including lack of honesty, weak follow-through, boring formats, blame, and discussing only safe topics.

What Is a Sprint Retrospective?

A Sprint Retrospective is the Scrum event where the Scrum Team inspects how the last sprint went and identifies ways to improve.

The Scrum Team may discuss people, interactions, process, tools, quality, Definition of Done, collaboration, stakeholder involvement, or anything else that affected the work.

The retrospective is about the system of work, not blaming individuals.

A Scrum Team may notice an improvement opportunity at any time during a sprint and act on it immediately. The retrospective simply ensures there is a regular time to step back and look more deliberately at how the Scrum Team is working.

When Does the Sprint Retrospective Happen?

The Sprint Retrospective usually happens after the Sprint Review and before the next Sprint Planning meeting.

That timing matters. The Scrum Team has just completed a sprint and received feedback in the Sprint Review. Before starting the next sprint, the Scrum Team takes time to decide what it wants to improve.

The maximum timebox is three hours for a one-month sprint. Shorter sprints usually need less time. Many Scrum Teams can have a useful retrospective in under an hour.

Who Attends the Sprint Retrospective?

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

The Product Owner is part of the Scrum Team and should participate. Product ownership affects how the Scrum Team works. Product Backlog clarity, stakeholder feedback, Product Owner availability, and scope tradeoffs may all be relevant retrospective topics.

The Scrum Master often facilitates, especially while the Scrum Team is learning to hold useful retrospectives. But the Scrum Master should not own improvement alone. The whole Scrum Team owns improvement.

What Happens in a Retrospective?

There are many ways to run a retrospective.

A simple format is start-stop-continue:

What should we start doing?
What should we stop doing?
What should we continue doing?

Another common approach is to ask:

What went well?
Where can we improve?
What should we try next?

The format matters less than the outcome. The Scrum Team should leave with one or a few improvements it intends to try in the next sprint.

A retrospective that produces a long list of ideas but no change will quickly lose credibility.

Choose a Few Improvements

Scrum is built on continuous improvement, but that does not mean the Scrum Team should try to fix everything at once.

Choose one or two improvements that matter. Make them specific enough to act on. Decide who will help. Make the improvement visible during the next sprint.

For example:

“We will involve a tester before coding begins on each new story.”
“The Product Owner will be available from 9:00 to 9:30 each morning for questions.”
“We will limit work in progress to two product backlog items at a time.”
“We will update the Definition of Done to include browser testing for the newly supported browser.”

Small changes made consistently are better than ambitious improvement lists no one revisits.

Create Safety Without Avoiding Hard Topics

A good retrospective needs psychological safety.

People need to be able to raise problems without fear that comments will be used against them. That does not mean the retrospective should avoid difficult topics. It means difficult topics should be handled constructively.

The Scrum Team should be able to discuss conflict, quality problems, missed expectations, weak collaboration, poor stakeholder engagement, or leadership interference without turning the meeting into blame.

A useful standard is this: criticism should point toward improvement. Complaining without a possible improvement rarely helps.

Follow Through During the Next Sprint

Retrospectives fail when improvements disappear after the meeting.

The Scrum Team should keep selected improvements visible. They might add an improvement item to the Sprint Backlog, mention it during the Daily Scrum, revisit it in the next retrospective, or make it part of the working agreement.

The Scrum Master can help with follow-through, but the whole Scrum Team should care.

When people see retrospective actions lead to real change, they become more willing to raise meaningful issues.

Common Sprint Retrospective Problems

The Same Issues Repeat

If the same topics appear every retrospective, the Scrum Team may not be acting on improvements, or the impediment may be outside the Scrum Team’s control.

Repeated issues should become visible. The Scrum Master may need to help escalate organizational impediments.

People Are Not Honest

A retrospective without honesty has little value.

The Scrum Team may need to improve trust, clarify that the retrospective is not for blame, or start with smaller issues until people are comfortable raising harder ones.

The Meeting Becomes Therapy Without Change

Talking can help, but Scrum needs inspection followed by adaptation.

The retrospective should end with a decision about what the Scrum Team will do differently.

The Format Gets Boring

A simple format can work well. But if the Scrum Team is disengaged, try a different structure.

Changing the format is not the goal. Better conversation is the goal.

Only Safe Topics Are Discussed

If the Scrum Team never discusses the real problems, the retrospective becomes a ritual.

A good Scrum Master helps the Scrum Team build enough safety to discuss what actually matters.

Too Many Improvements Are Selected

A long list can feel productive in the meeting and fail immediately after.

Pick a small number of improvements and follow through.

Before You End the Retrospective

Before ending a retrospective, the Scrum Team should know:

What improvement it will try next sprint
Why that improvement matters
Who needs to help
How the improvement will stay visible
When the Scrum Team will check whether it helped

This is not meant to make retrospectives bureaucratic. It is meant to make improvement real.

FAQ

What is a sprint retrospective?

A Sprint Retrospective is the Scrum event where the Scrum Team inspects how it worked during the last sprint and chooses improvements for the next sprint.