A sprint retrospective is a recurring meeting, held at the end of every sprint, where the Scrum team looks at how it worked together and agrees on one or two changes to try next time. It is not a status report or a venting session, though it can slide into either without owned follow-through. In the Scrum framework it is a fixed ceremony with a specific place in the calendar, a specific guest list, and a specific question it exists to answer: not what did we build, but how did we build it, and what should change.
What changed in 2026
- Async and AI-assisted retros grew further. Tools now draft a summary of the sprint (commits, tickets closed, incidents) before the meeting starts, so the team spends less time reconstructing the sprint and more time discussing it.
- Shorter sprints forced shorter retros. Teams running one-week sprints increasingly run a tight 20 to 30 minute retrospective rather than the traditional hour, scaling the ceremony to the cycle instead of running the same format regardless of sprint length.
- The retrospective and the incident postmortem got clearly separated. As more teams formalized blameless postmortems for production incidents, the sprint retrospective narrowed back to its original scope: the team process, not specific failures.
- Facilitation rotated more widely. Fewer teams default to the Scrum Master running every retro; rotating the facilitator among developers became a common way to keep the format from going stale.
Where it sits in the sprint cycle
A sprint has four Scrum ceremonies, each answering a different question. The retrospective is deliberately last, after the work is done and reviewed, so the conversation is about the process the team just used rather than the code or the backlog.
| Ceremony |
Question it answers |
Who attends |
Typical timing |
| Sprint planning |
What will we build this sprint |
Whole Scrum team |
Start of sprint |
| Daily standup |
What is blocking us right now |
Developers, Scrum Master |
Every working day |
| Sprint review |
What did we build, does it work |
Scrum team plus stakeholders |
End of sprint |
| Sprint retrospective |
How did we work, what should change |
Scrum team only |
End of sprint, after review |
The distinction between sprint review and sprint retrospective trips up a lot of new teams. The review is a demo with an outside audience; the retrospective is an internal conversation with the door closed. Mixing the two, discussing team friction in front of a stakeholder or demoing a feature mid-retrospective, undermines both.
What actually happens in the meeting
Most retrospectives, regardless of format, move through the same rough arc:
- Set the stage. A quick check-in question to get everyone talking before the substantive discussion starts.
- Gather data. What happened this sprint — a timeline, a set of sticky notes, whatever surfaces facts rather than opinions first.
- Generate insights. Why did the good things go well and the bad things go badly. This is where patterns get named.
- Decide what to do. Narrow everything down to one to three specific changes, each with an owner.
- Close. Confirm the changes and, ideally, revisit them at the start of the next retrospective.
The specific format — Start-Stop-Continue, Mad-Sad-Glad, a plain three-question round — matters far less than whether step four produces something concrete. A retrospective that ends in a general conversation and no commitments is a retrospective in name only.
Why the ceremony exists
The retrospective is how a Scrum team improves itself on a cadence, without waiting for a crisis to force the conversation. Agile process without a working retrospective tends to calcify: the same friction repeats sprint after sprint because nobody has a standing, protected slot to name it and fix it. That is also why the Scrum Guide keeps it separate from a root cause analysis exercise — a retrospective is broader and more frequent than a formal RCA, which is usually reserved for a specific, significant problem.
FAQ
Is a sprint retrospective the same as a postmortem?
No. A postmortem is triggered by a specific incident, usually a production failure, and digs into what caused it. A sprint retrospective happens every sprint regardless of whether anything went wrong, and covers how the team works in general, not one specific failure.
How long should a sprint retrospective be?
A common rule of thumb is 45 minutes per week of sprint length, so roughly 45 minutes for a one-week sprint and 90 minutes for a two-week sprint. Many teams run shorter than that once the format is well practiced.
Who facilitates a sprint retrospective?
Traditionally the Scrum Master, though many teams rotate facilitation among developers to keep perspectives fresh and prevent the ceremony from feeling owned by one role.
What if the team genuinely has nothing to discuss?
It is rare, but if it happens repeatedly, treat it as a signal itself — either the format has gone stale or people do not feel safe raising real issues, not that the sprint was actually friction-free.
Where to go next