A home-robot company's operations director wants the Sprint Review reframed as a formal sign-off gate, where the Increment cannot move toward release unless she personally approves it in the meeting. Why does this conflict with the Scrum Guide's description of the Sprint Review?
Select an answer to reveal the explanation.
Short Explanation
A gate has one person holding a stamp; a working session has a room full of people figuring things out together. The Scrum Guide sets up the Sprint Review as the second kind — everyone inspects the real Increment and adjusts the plan collaboratively, and no single stakeholder holds veto power over that. Turning it into a personal approval checkpoint changes what the meeting is for.
Full Explanation
The Scrum Guide frames the Sprint Review as an inspect-and-adapt working session — the Scrum Team presents results to stakeholders, discusses progress, and the whole group collaborates on what to do next, with the Product Backlog adjusted as needed. Nothing in that description installs a single stakeholder as an approval authority; the Increment is a body of Done work the Developers already produced according to the Definition of Done, and the Review is where its implications get discussed, not where its validity is decided by one vote. Stakeholders attending is exactly what the Guide expects — the problem isn't attendance, it's converting attendance into unilateral control. The timebox (up to four hours for a one-month Sprint, scaled down for shorter Sprints) is meant for genuine collaboration, not too short for it — length isn't the issue here. And the Increment does not need to already be in production to be reviewed; in fact the Review is often where decisions about releasing it get made, so requiring prior release would invert the event's purpose. A concrete check: watch whether the Product Backlog actually changes as a result of the conversation — a genuine working session leaves a trace in the backlog, while a rubber-stamp gate does not.