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.
Who Attends the Sprint Retrospective?
The whole Scrum Team attends: the Product Owner, Scrum Master, and Developers.
The retrospective is about improving how the Scrum Team works together.
When Is the Sprint Retrospective Held?
It is usually held after the Sprint Review and before the next Sprint Planning meeting.
That timing lets the Scrum Team learn from the sprint before starting the next one.
How Long Should a Sprint Retrospective Be?
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.
What Is a Good Retrospective Format?
Start-stop-continue is a simple and useful format:
- What should we start doing?
- What should we stop doing?
- What should we continue doing?
Many other formats can work as long as the Scrum Team has an honest conversation and chooses useful improvements.
What Should Happen After a Retrospective?
The Scrum Team should act on the improvement it selected.
Make the improvement visible during the next sprint and revisit whether it helped.
Sprint Retrospective Resources
A practical start-stop-continue format that works well for many Scrum Teams.
Practical advice for improving honesty, engagement, follow-through, and usefulness.
Useful when quieter team members are not being heard.
Helpful when retrospectives repeatedly surface overload, burnout, or unrealistic expectations.