Sprint Review vs Retrospective

The Sprint Review is about the product; the Sprint Retrospective is about the team. At the Review, the Scrum Team and key stakeholders inspect what was built during the Sprint, discuss progress towards the Product Goal and decide what to do next, which often changes the Product Backlog. At the Retrospective, the Scrum Team alone looks at how it worked, its people, interactions, processes, tools and Definition of Done, and chooses the changes that will make it more effective. The Review comes first; the Retrospective ends the Sprint. Both are timeboxed, to four hours and three hours respectively for a one-month Sprint.

This page is about how the two events differ. For questions and formats to use inside a retrospective, see sprint retrospective questions.

The Sprint Review, per the Scrum Guide

The 2020 Scrum Guide↗ (opens in a new tab) gives the Sprint Review one purpose: to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of its work to key stakeholders, and progress towards the Product Goal is discussed. The team and stakeholders review what was accomplished and what has changed in their environment, then collaborate on what to do next. The Product Backlog may be adjusted to meet new opportunities.

Two sentences in the guide are worth holding on to. The Review is a working session, and the team should avoid limiting it to a presentation. And the Review is never a gate to releasing value: the guide says an Increment may be delivered to stakeholders before the end of the Sprint. What is shown at the Review is the sum of the Increments, and only work that meets the Definition of Done can be presented at all.

The Sprint Retrospective, per the Scrum Guide

The Sprint Retrospective↗ (opens in a new tab) exists to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done; identifies the assumptions that led it astray; discusses what went well, what problems it met and how they were or were not solved; and identifies the most helpful changes. The most impactful improvements are addressed as soon as possible, and may even be added to the Sprint Backlog for the next Sprint.

The practice predates Scrum’s wording. The Agile Alliance’s entry on the heartbeat retrospective↗ (opens in a new tab) credits Norm Kerth with popularising the term “retrospective”, chosen over “debriefing” or “post-mortem” for its more positive connotations, and notes that a manager’s presence may inhibit discussion of performance issues. That is one reason the retrospective is usually kept to the team.

Sprint review vs retrospective, side by side

• Question it answers. Review: are we building the right thing, and what next? Retrospective: are we working the right way, and what will we change?
• Subject. Review: the product and the Increment. Retrospective: the team’s process, tools, collaboration and Definition of Done.
• Who attends. Review: the Scrum Team and key stakeholders, such as customers, users, sponsors or other teams. Retrospective: the Scrum Team: Product Owner, Scrum Master and Developers.
• Inputs. Review: the Increment, the Sprint Goal, the Product Backlog and what has changed in the market or organisation. Retrospective: how the Sprint went, what happened, the Definition of Done, and the actions from the last retrospective.
• Outputs. Review: a revised Product Backlog and a shared view of what to do next. Retrospective: a small number of improvements, each with an owner, some of which go into the next Sprint Backlog.
• Timebox. Review: at most four hours for a one-month Sprint. Retrospective: at most three hours for a one-month Sprint. For shorter Sprints both are usually shorter.
• Position. Review: the second-to-last event of the Sprint. Retrospective: the last; it concludes the Sprint.

One Sprint, both events

A team building a class-booking app ends a two-week Sprint whose goal was that members can move a booking themselves. At the Review, which runs for an hour, two studio managers try moving bookings on a phone. One asks what happens to a class pack credit when a booking moves to a more expensive class. Nobody had thought of it. The Product Owner adds an item for it near the top of the Product Backlog, and the group agrees the waiting list can wait a Sprint.

At the Retrospective the next morning, the stakeholders have gone. The team notices that the credit question should have come up in refinement, and that two stories sat finished for three days waiting for a tester. They agree two changes: invite one studio manager to refinement once a Sprint, and pair on testing before anyone starts a new item. Each change has a name against it.

The same Sprint produced two different kinds of finding. The credit question is about the product, so it belongs to the Review and ends up in the backlog. The testing queue is about the team, so it belongs to the Retrospective and ends up in the way the team works.

Common mix-ups

• Running the Review as a demo. A slide deck and polite applause is a presentation, which the guide asks teams to avoid. The point is to decide what to do next with the people affected.
• Merging the two to save time. Stakeholders in the room change what the team is willing to say about itself, and process talk crowds out the product.
• Waiting for the Review to release. The Review is not a gate; finished work can reach users during the Sprint.
• Showing work that is not done. Items that miss the Definition of Done are not presented; they go back to the Product Backlog.
• Discussing the product at the Retrospective. “We should build X next” belongs at the Review or in refinement. The Retrospective asks how the team worked, not what it built.
• Retrospective actions with no owner. A list of good intentions in the notes is forgotten by the next Sprint. Put each action where the rest of the work is.

Outside Scrum, and without sprints

Many teams use the same two meetings under other names. The GOV.UK Service Manual’s page on agile tools and techniques↗ (opens in a new tab) describes a team review, also called a sprint review or show and tell, where the team demonstrates its work and can invite stakeholders such as directors or suppliers, and a separate retrospective where the whole team talks about what is going well and what is not, suggesting 60 to 90 minutes for it.

Teams that work in a continuous flow have no Sprint to end, but still need both conversations. The Kanban Guide↗ (opens in a new tab) says it is common practice to review the workflow from time to time, but that there is no requirement to wait for a formal meeting at a regular cadence to change it. Two patterns work:

• A product review on a fixed rhythm, such as every two or four weeks, or after each release: show what shipped to the people who use it, and reorder the backlog with them.
• A process review triggered by evidence: when items age well past what the team expects, when work queues in one place, or after an incident. It can also sit on the calendar, monthly.

Keep them separate for the same reasons as in Scrum: different questions, different people.

Both events on a fenbs board

fenbs has no sprints, no review screen and no retrospective screen; both meetings happen wherever your team talks. The board supplies the evidence for each and holds what comes out.

• For the Review: the Completed lane shows what finished, and each task records how it ended, so work closed as Won’t fix or Duplicate is not mistaken for delivery. The “Completed, not tested” filter shows what nobody has checked yet.
• Stakeholders can take part between reviews if you add them to a team board with the Client role: they see the board and can comment on any task, but cannot change anything.
• Changes of direction agreed at the Review go on the Decisions page, with who decided and why, and new items go into To Do with a priority from 1 to 10.
• For the Retrospective: History lists every change with who made it and when, including moves made by an AI assistant, so the team can see where work waited instead of relying on memory.
• Retrospective actions become tasks, usually enhancements, with the problem in the note and the experiment in the plan. Lessons about working with an assistant go into the board’s AI context, which every connected assistant reads.