Sprint retrospective: definition, length and agenda in Scrum
What the sprint retrospective is in Scrum: when it happens, how long it lasts, who attends and what should come out of it.
Blog5 min read
The sprint retrospective is the last event of a Scrum sprint: the team stops for an hour to look at how it worked, and decides what it will change in the next sprint. It is also the event most often cut short, then skipped, as soon as the schedule gets tight. Here is what the Scrum Guide says about it, how much time to plan depending on sprint length, and what has to come out of it for it to be worth holding.
What is a sprint retrospective?
In the Scrum Guide, the sprint retrospective has a precise purpose: to plan ways to increase quality and effectiveness. It looks at the sprint that is ending from every angle: the people, their interactions, processes, tools, and the Definition of Done. What went well, what went wrong, and how those problems were solved, or not.
It is different from the sprint review, with which it is often confused. The review looks at the product: what was delivered, with the stakeholders, to adjust the rest of the backlog. The retrospective looks at the team: how it works, among its members only. One answers “what did we build?”, the other “how did we build it?”.
When does it happen?
The retrospective closes the sprint. It comes after the sprint review and before the next sprint planning, which gives it a logical place: the review’s findings are fresh, and the changes the team decides on can go straight into the planning that follows.
In practice, many teams hold it on the same day as the review, in the afternoon. Avoid gluing it to the planning without a break: a tired team decides fast and badly, which is exactly what the retrospective is meant to prevent.
How long is a sprint retrospective?
The Scrum Guide sets a ceiling: three hours at most for a one-month sprint, and usually less for a shorter one. A common rule of thumb is about 45 minutes per week of sprint:
- One-week sprint: 45 minutes.
- Two-week sprint: one hour to an hour and a half, the most common case.
- Three-week sprint: about two hours.
- One-month sprint: three hours at most.
These are ceilings, not targets. A well-practiced team with a facilitator who keeps time often runs a very good retrospective in one hour for a two-week sprint. What matters is that the length is announced and kept.
Who attends?
The whole Scrum team: the developers, the Product Owner and the Scrum Master. Whether the Product Owner should be there is sometimes debated, but the Scrum Guide includes them without ambiguity: they are part of the team, and many sprint problems (shifting priorities, late specs) go through them.
Managers and stakeholders are not invited by default. Their presence alone is often enough to make the cards more cautious. If the team wants, they can join a specific session, on a topic that concerns them.
The Scrum Master facilitates most often, but nothing requires it. Rotating facilitation among team members is a good way to keep the session fresh, and to stop it becoming “the Scrum Master’s meeting”.
How does it run?
Most teams follow a five-step flow: open the session, gather the facts of the sprint, understand them by grouping and voting, decide on action items, then close. The discussion should take most of the time, with gathering and opening kept short. Each step, with timings and the facilitator’s role, is covered in the guide to running an agile retrospective.
The format, meaning the columns of the board, depends on what the sprint brought up: a “Went well / To improve” for an ordinary sprint, a Speedboat ahead of a deadline, a Mad / Sad / Glad after a tense sprint. The six most used are compared in our article on retrospective formats.
What should come out of it?
One or two concrete action items, each with an owner and a due date. The Scrum Guide notes that the most impactful improvements may be added to the next Sprint Backlog: it is the best way to guarantee them time, instead of leaving them to compete with everything else.
The classic trap is a list of ten good resolutions that nobody reads again. Open every retrospective with the status of the previous one’s action items: done, not done, dropped. That is what proves to the team that the session changes something. Why action items get lost, and how to write them so they get done, is the subject of a separate article.
Frequently asked questions
Can we skip a retrospective when the sprint was busy?
A difficult sprint is exactly when it helps most. Shorten it rather than cancel it: thirty minutes focused on a single topic beat a postponed session that never happens. If the team regularly wants to skip it, that is a sign it is going through the motions, and that is the problem to address.
Should we hold a retrospective every sprint?
Yes: in Scrum, it is one of the five sprint events. But its form can vary: changing the format, the facilitator or the setting from time to time prevents wear. A team outside Scrum gains just as much from keeping the same meeting at a fixed rhythm, every two or three weeks.
Does the sprint retrospective work remotely?
Yes, provided there is a tool where everyone writes at the same time, a period of silent writing and a vote. The pitfalls specific to remote work (cameras, silences, teams half in the room) are covered in our tips for remote retrospectives.