Sprint Retrospective
The Sprint Retrospective is the Scrum event that closes each Sprint, in which the Scrum Team inspects how the Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done, and decides on the most helpful improvements. It is defined in the Scrum Guide by Ken Schwaber and Jeff Sutherland and is timeboxed to a maximum of three hours for a one-month Sprint, shorter for shorter Sprints. The Guide sets the purpose and the timebox but not a facilitation sequence, so teams choose their own format for each session.
Facilitation script
- 1
Open the session, restate its purpose and review the status of the improvements agreed last time.
10 min - 2
Individuals note silently what went well and what problems came up during the Sprint, then post their notes.
10 min - 3
Group the notes and let the team choose the two or three topics that matter most.
10 min - 4
Discuss the chosen topics: what happened, how it was handled and which assumptions turned out to be wrong.
25 min - 5
Collect possible improvements and choose one or two that would help the most.
15 min - 6
Agree owners and the first step for each improvement, add them to the next Sprint's work and close with a short check-out.
10 min
Tips
Vary the format for gathering input from Sprint to Sprint, for example Sailboat, Four Ls or Mad Sad Glad, while keeping the purpose the same.
Commit to one or two improvements that the team can complete in the next Sprint; a long list rarely gets done.
If the Scrum Master is facilitating, find a way for them to contribute as a team member too, or rotate the facilitation.
Keep the conversation on how the team works, since the product increment is the subject of the Sprint Review.
Common pitfalls
Agreeing improvements and never following up; after a few Sprints people stop believing the session changes anything and stop raising issues
Using the same format every time, so answers become routine and the session turns into a formality
Spending the whole timebox on complaints about things outside the team's control, leaving no time to choose something the team can change
Skipping the retrospective when the Sprint was stressful, which is when the team most needs to look at how it works
Turning the session into a search for who was at fault; people become defensive and the real causes stay hidden
Variations
For a two-week Sprint, 60 to 90 minutes is typical; the three-hour limit applies to a one-month Sprint. Teams that do not use Scrum hold the same kind of session on a fixed rhythm, for example every two or four weeks. Distributed teams run it on an online whiteboard or collect input asynchronously beforehand and use the call for discussion and decisions. Named formats such as Sailboat, Starfish, Four Ls, Mad Sad Glad or Start, Stop, Continue are ways of structuring the data-gathering part of this event.
Where it fits
When to use it
At the end of every Sprint, as the last event before the next Sprint Planning
A team works in a regular rhythm and wants a fixed moment to adjust how it works
Small irritations in collaboration or tooling keep coming up and never get addressed during delivery work
The Definition of Done no longer matches what the team actually does and needs to be reviewed
A new team is forming its working habits and needs frequent, low-stakes opportunities to correct course
When not to use it
The aim is to inspect the product increment with stakeholders; that is the Sprint Review
A single serious incident needs careful reconstruction; hold a dedicated After Action Review instead of squeezing it into the regular slot
A long project or release has just ended and you want to look back over months; use a Timeline Retrospective with more time
The issue is a conflict between two individuals; address it directly or with mediation, not in front of the whole team
Managers want to use the session to assess individual performance; this destroys candour, so keep evaluation out of the event
Related methods
Further reading
Frequently asked questions
What is Sprint Retrospective?▾
The Sprint Retrospective is the Scrum event at the end of each Sprint in which the Scrum Team looks at how it worked and plans ways to increase its quality and effectiveness. It covers individuals, interactions, processes, tools and the Definition of Done. It concludes the Sprint.
How long should a Sprint Retrospective be?▾
The Scrum Guide sets a maximum of three hours for a one-month Sprint and says the event is usually shorter for shorter Sprints. Many teams on two-week Sprints use 60 to 90 minutes. Less than 45 minutes rarely leaves time to get from observations to an agreed improvement.
Who attends the Sprint Retrospective?▾
The whole Scrum Team: the Developers, the Product Owner and the Scrum Master. Stakeholders and line managers from outside the team are normally not present, because the team needs to speak openly about its own work.
What is the difference between a Sprint Review and a Sprint Retrospective?▾
The Sprint Review inspects the outcome of the Sprint, the product increment, together with stakeholders and decides what to do next with the product. The Sprint Retrospective follows it and inspects how the team worked. One looks at the product, the other at the process and the collaboration.
Does the Scrum Guide prescribe a retrospective format?▾
No. It describes the purpose, what the team inspects, the expected result and the timebox. How the conversation is structured is up to the team, which is why so many named retrospective formats exist.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Sprint Retrospective into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Ken Schwaber and Jeff Sutherland, The Scrum Guide (2020).