Sprint Review and Sprint Retrospective: Inspecting the Product and the Process

Version note: This post is based on the Scrum Guide 2020 (November 2020, Ken Schwaber and Jeff Sutherland); as of November 2026 it is still the current official version on scrumguides.org. Timebox values are for a one-month Sprint, as in the Guide.

Guess First

Bookstore's Sprint 9 Review: Selin shows eight slides on the projector, Zeynep plays a screen recording of the return screen, the sales manager says "looks good", the meeting ends after 40 minutes and nobody looks at the Product Backlog. The next day, in the Retrospective, the team discusses the same three complaints for the third time: code review waits too long, staging goes down often, too many meetings. The action written down is "let's be more careful".

Which of these two events is further from the Guide's definition? And what should have changed by the end of the Review? Write down your guess; it becomes clear once we look at the purpose of the two events.

The Sprint Review: A Working Session, Not a Demo

The Guide states the purpose of the Sprint Review as inspecting the outcome of the Sprint and determining future adaptations. The Scrum Team presents the results of its work to key stakeholders, and progress toward the Product Goal is discussed. During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment; based on that, the attendees collaborate on what to do next. The Product Backlog may be adjusted to meet new opportunities.

The clearest sentence in this section of the Guide: the Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation. Bookstore's Sprint 9 Review was exactly a presentation. The stakeholders watched, liked it and left; they neither tried the Increment themselves nor described what had changed in their environment. No inspection happened, so no adaptation either.

The Review is the second to last event of the Sprint; it is timeboxed to a maximum of four hours for a one-month Sprint and is usually shorter for shorter Sprints. Bookstore sets aside 90 minutes for its two-week Sprint.

Bookstore's Review Agenda

From Sprint 10 onward, the team structured the Review like this:

The second row changed the most. While filling in the return form, Elif from the support team asked what a customer who does not know their order number should do; the form only opened with an order number. That question had never come up in the slides. In the third row Elif brought a number: since the first version of the return flow went live, support emails about returns had dropped from 120 to 85 a week. The Product Goal's target was under 20; there is still a way to go, but the direction is right.

In the fourth row the Product Backlog changed: "Start a return from order history" moved up to third place, and "Email notification for return status" moved further down, because Elif's data showed customers were tracking returns in the panel. The Review's output was not applause but a changed Product Backlog.

What Is Shown at the Review, and What Is Not?

The rule from the previous post applies here: an item that does not meet the Definition of Done cannot be presented at the Review. The point of the rule is not misleading stakeholders; a sales manager who sees an "almost done" screen may count it as done and make a promise to a customer. At Bookstore, items that are not Done are not shown, but the first row of the agenda states openly why they are not Done.

The second rule: the Review is not an approval or sign-off meeting. The Guide says an Increment may be released before the Sprint ends and that the Review should never be a gate to releasing value. Waiting for a stakeholder to say "I approve" at the Review ties release to a ceremony held every two weeks. At Bookstore most of the work that reaches the Review is already in production; the stakeholders talk about it from there.

The Sprint Retrospective: Inspecting the Process

In the Guide, the purpose of the Retrospective is 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 their Definition of Done. Assumptions that led them astray are identified and their origins explored. The team discusses what went well during the Sprint, what problems it encountered, and how those problems were or were not solved.

Then the team identifies the most helpful changes to improve its effectiveness. In the Guide's words, the most impactful improvements are addressed as soon as possible; they may even be added to the Sprint Backlog for the next Sprint. The 2017 Guide was more prescriptive here: the Sprint Backlog had to include at least one high-priority improvement identified in the previous Retrospective. The 2020 version softened that requirement but kept the intent: improvement belongs in the team's actual work plan, not on a separate "process list".

The Retrospective concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint; for shorter Sprints it is usually shorter. Bookstore sets aside 75 minutes for its two-week Sprint.

Retro Formats

The Guide gives no format. The three most used in practice, and when Bookstore picks each:

More important than the format is giving the session a structure. The five stages from Esther Derby and Diana Larsen's book "Agile Retrospectives: Making Good Teams Great" (2006) are still the most useful skeleton: set the stage, gather data, generate insights, decide what to do, close. Most complaint sessions get stuck in the second stage; data is gathered, but no insight or decision comes out of it.

Getting an Action into the Sprint Backlog

In the Sprint 9 Retrospective the team used the timeline format. The same thing showed up three times on the line: pull requests waited about two days for code review on average, and in the meantime their authors started on something else. The action written for this in the previous Retrospective was "let's be more careful": not measurable, no owner, no idea when it is done.

This time the action was written like this: "An opened pull request gets its first review within the same working day; when the Daily Scrum walks the board from right to left, the Code Review column comes first. Owner: Emre. Measure: the average time from opening a pull request to its first review, at the end of the Sprint." The item went into Sprint 10's Sprint Backlog, next to the Sprint Goal. By the end of Sprint 10 the average wait had dropped from 2.1 days to 0.6 days; the team inspected this in the first five minutes of the Sprint 10 Retrospective and turned the action into a permanent working agreement.

The three qualities of a good Retrospective action show in this example: small (it can be tried within one Sprint), with a clear owner, and with a measurable result. Do not forget that the Retrospective inspects the Definition of Done as well; the OpenAPI line in Bookstore's Definition of Done was also a Retrospective action.

In Production: What to Watch

For the health of the Review, Bookstore looks at two numbers: how many of the key stakeholders came, and how many changes were made to the Product Backlog at the end of the Review? If the backlog has not changed in two Reviews in a row, either the product is going perfectly or the Review has turned into a presentation. The second is more likely.

For the Retrospective: how many actions were actually applied in the next Sprint, and in how many Retrospectives did the same topic come back? The same complaint arriving for the third time shows that earlier actions failed, not the Retrospective; sometimes it also shows the problem lies outside what the team can change. Then the topic moves to the Scrum Master's service to the organization.

At scale, if several teams work on the same product, a single joint Review is often best; stakeholders see the integrated Increment and cross-team dependencies become visible. Retrospectives can be held first within each team and then in a cross-team session; Nexus defines this with its own events.

Common Pitfalls

The Review turning into an approval or sign-off meeting. The stakeholder's role is not to approve but to inspect and contribute to what comes next. A Review that waits for a signature ties release to a two-week ceremony.

Turning the Review into a slide show presented only by the Product Owner. The Guide says the Scrum Team presents the results and the event is a working session; slides do not replace that.

The Retrospective becoming a complaint session that produces no action. Data is gathered, everyone feels better, but nothing enters the Sprint Backlog. The next Sprint starts with the same problems.

A manager joining the Retrospective and trust disappearing. The Guide defines the Retrospective as an event of the Scrum Team; in a setting where the team cannot talk about its real problems, inspection stays superficial.

Using the same format every Sprint. After a while the team memorizes the answers; changing the format means looking at the same Sprint from a different angle.

A Small Experiment

★☆☆ Write down what changed in the Product Backlog at the end of your last Review. If nothing changed, add a 20-minute section to the next Review in which stakeholders try the Increment with their own hands.

★★☆ List the actions from the last three Retrospectives and write next to each its owner, its measure and whether it was applied in the next Sprint. Rewrite the actions missing any of these three.

★★★ Plan the next Retrospective with Derby and Larsen's five stages; give each stage an activity and a duration. After the session, note which stage took the most time and in which stage the action became clear.

Block A ends here: we have seen all the accountabilities, events, artifacts and commitments in the Guide. With the next post we go out into the field: what metrics such as velocity, burndown and Sprint Goal success really show, what they hide, and how Goodhart's law can hurt a team.