skip to content

Why is the Sprint Review a working session rather than a sign-off demo?

level: middleimportance: should knowfreq 57%

answer

  1. Something must change because of it
  2. Stakeholders are collaborators, not an approval board
  3. Inspect the product, not the team
  4. The output is an adapted Product Backlog

basics

~20 s

The Sprint Review exists so the Scrum Team and stakeholders inspect the Increment together, discuss what changed outside the team, and adapt the Product Backlog on the spot. Its output is a revised backlog, not an approval.

solid answer

~50 s

The Sprint Review is the Sprint's inspection of the **product**, and Scrum makes its output an adaptation rather than a verdict. The Scrum Team shows what was finished, but the showing is the opening move: the point is the conversation that follows about what has changed - in the market, in the budget, in what users did with what was delivered last - and what the team should do next. The **Product Backlog** is adjusted during the event or immediately after so the conversation leaves a trace. Framing it as a sign-off breaks two things. It turns stakeholders into reviewers rather than collaborators, so they arrive with approval on their minds instead of information. And it implies the work needs their permission, when only finished work is presented in the first place. It is capped at four hours for a one-month Sprint.

go deeper

for a junior

Know that the Sprint Review happens at the end of the Sprint, involves stakeholders, and looks at what was built. Do not describe it as the meeting where the team is given permission to deliver.

for a middle

Explain the output - an adapted Product Backlog - and contrast the Review with the Retrospective by subject rather than by timing. Be ready to give the four-hour cap for a one-month Sprint.

for a senior

An interviewer at this level wants a story: a Review that had become theatre, what you changed, and how you got the right people into the room. Say what evidence told you it was working again.

for a principal

Own the framing question of what your organisation believes the Review is for. Where delivery genuinely needs external authorisation, be ready to say where that decision belongs instead and why bolting it onto this event corrupts both.

## The purpose is adaptation, not approval The Sprint Review brings the Scrum Team together with the stakeholders who care about the product, to inspect the **Increment** produced during the Sprint and to work out what to do next. Its result is an adapted **Product Backlog**: items added, removed, re-ordered or rewritten because of what the room learned. It is capped at four hours for a one-month Sprint, and less for shorter ones. Nothing in that purpose is an approval. The framework has no step where a stakeholder authorises the work as acceptable; the Product Owner is accountable for the product's value continuously, and only finished work is shown at all. The Review exists because the people outside the team hold information the team does not - how the last delivery behaved in real use, what a regulator has just announced, which customer changed their mind - and the cheapest place to collect that information is standing in front of the working software. ## What a working session actually looks like 1. **Show what exists**, briefly, and only what is finished. The demonstration is the opening, not the event. 2. **Say what did not get done**, and why, without dressing it up. That is information, and it belongs in the ordering conversation that follows. 3. **Discuss what changed outside the team** since the last Review: the market, the budget, the users, the constraints, the deadline nobody mentioned. 4. **Change the Product Backlog** in the room or immediately after, so the conversation leaves a trace in the thing that drives the next Sprint. A crude but useful measure: if the Scrum Team is talking for most of the event, it is a presentation. If the team shows briefly and then the stakeholders talk, it has a chance of being a review. ## Sign-off framing versus inspection framing | | Sign-off framing | Inspection framing | | --- | --- | --- | | The stakeholder's job | Approve or reject the work | Supply information and priorities | | Preparation | Rehearsal and slides | Working software, ready to show | | Unfinished work | Hidden, because it looks bad | Stated, because it changes the ordering | | Output | A decision about the Sprint just past | A changed Product Backlog for the next | | Characteristic failure | Theatre, and a team that games it | Nobody attends, so nothing is learned | The sign-off framing is self-reinforcing. A team that is judged at the Review starts optimising for the Review: it saves demonstrable work for the event, avoids showing anything half-explored, and stops raising problems in front of the very people who could solve them. Within a few Sprints the event is generating confidence rather than information, which is the opposite of what it was installed to do. ## Who belongs in the room - The whole Scrum Team. The Developers show their own work rather than having it narrated for them, and they hear the reaction first-hand. - The stakeholders the Product Owner invites: whoever holds information about the product's value or its constraints. - Enough decision-making weight that the ordering conversation is real and not a request to be relayed to somebody else later. Empty attendance is an impediment, not a diary problem. If the people who feel the consequences of the product never come, the team adapts its Product Backlog on its own assumptions and finds out several Sprints later whether they were sound. The response is to work out who actually decides and go to them if they will not come to you. ## The failure modes worth naming in an interview - **The rehearsed demo.** Slides instead of software, and a script that routes carefully around everything unresolved. - **The approval gate.** Work is treated as undeliverable until stakeholders bless it, which inserts a manual checkpoint in front of every Increment and makes the event a bottleneck. - **The Review that changes nothing.** The event ends, everyone leaves, and the Product Backlog is identical the next morning. - **The Review folded into the Retrospective.** One meeting, two subjects, and the team's own improvements lose to the product conversation every time. - **The Product Owner as sole speaker.** Stakeholders never hear from the people who built the thing, and the Developers never hear a customer's reaction unfiltered. Saying which of those you have lived through, what you changed, and how you knew it had worked is what separates a memorised definition from experience of this event. The evidence that it worked is usually visible in the Product Backlog the following morning.

  • Nobody outside the Scrum Team turns up to your Sprint Review. What does that cost you?
    You lose the inspection the event exists for. Without the people who feel the consequences of the product, the team adapts the Product Backlog on its own assumptions and discovers a few Sprints later that it moved in the wrong direction. Treat empty attendance as an impediment: find out who actually decides, and go to them if they will not come to the event.
  • Should work that is not finished be shown at the Sprint Review?
    It should not be presented as part of the Increment, because a room treats anything demonstrated as delivered and plans on it. What is useful is being explicit about what did not get done and putting those items back into the Product Backlog for the Product Owner to order against everything else. That honesty is the adaptation the event is for.
  • Who should be doing most of the talking in a Sprint Review?
    The stakeholders, once the team has shown what exists. A Review in which the Scrum Team speaks for fifty of sixty minutes has produced a presentation. A Review in which the team shows for fifteen minutes and then listens has a chance of producing a changed Product Backlog, which is the only output that matters.

It is closer to a design critique than to a client presentation: the room exists to change the plan, not to applaud it.

saying these in an interview costs you the question

  • Calls it the meeting where stakeholders approve the release
  • Prepares slides instead of showing the working software
  • Believes only the Product Owner may speak to stakeholders
  • Ends the event without changing the Product Backlog at all
  • Confuses it with the Retrospective's focus on the team
  • Hides unfinished work so the event looks successful