At the Sprint Review for a transit-app real-time arrivals Increment, a facilitator starts a slide tour of every new screen. Riders and operations supervisors are in the room. How should the Product Owner steer the conversation?
Select an answer to reveal the explanation.
Short Explanation
A Review that is only a screen parade is dinner theater—pretty, but nobody checks whether riders waited less. Pull the room back to whether arrivals got more trustworthy, then move the backlog. The demo is a means, not the point.
Full Explanation
The Sprint Review inspects the Increment and the Product Backlog in light of progress toward the Product Goal. At Review for a transit-app real-time arrivals Increment, with riders and operations supervisors present, the Product Owner should steer toward whether the Increment changed rider wait-time outcomes and decide Product Backlog adaptations from that evidence. Screen tours can support inspection; they are not the point.
Letting the slide tour finish so every screen is demonstrated regardless of rider impact optimizes coverage of UI over civic outcomes. Asking Developers to present velocity and story-point burn as the Review's main topic imports internal planning metrics into stakeholder value inspection. Postponing stakeholder questions until a separate value workshop next month delays adaptation the Review should enable now.
Transit stakeholders deserve a Review that answers whether waits got better, not whether every new screen was applauded.
Exam caveat: PSPO II Sprint Review prioritizes outcome inspection and backlog adaptation over demo completeness or velocity reporting.
Operational check: open Review with the wait-time or trust outcome hypothesis, inspect the working arrivals Increment against it, and leave with explicit Product Backlog order changes.