How would you shift a Sprint Review from demo to working session?

WHAT THIS TESTS: The interviewer is checking whether you understand the Sprint Review as an empirical inspect and adapt event for the Scrum Team and its stakeholders, not a theatrical demo. Per the Scrum Guide, the team inspects the outcome of the Sprint and determines future adaptations. The question reveals whether you conflate the Review with a status report or a sign off ceremony, and whether you know how to create transparency around the Increment so that real adaptation can occur.

A GOOD ANSWER COVERS: First, reset the room by framing the agenda around the Sprint Goal and the Definition of Done, not a slide deck. Second, make the Increment tangible by running it in a production like environment so stakeholders interact with it directly. Third, shift from presentation to conversation by asking targeted questions about what has changed in the market, what assumptions were invalidated, and what new opportunities exist. Fourth, inspect the Product Backlog together by comparing what was done against the broader product direction, then add, remove, or re order items live with the Product Owner. Fifth, leave with a shared understanding of what is likely next, which feeds directly into the next Sprint Planning.

COMMON WRONG ANSWERS: A red flag is describing the Review as a demo where developers prove they did their homework or seek approval from a stakeholder. Another is suggesting the Scrum Master should control the conversation or that the Product Owner alone decides the future direction after the meeting. Saying the Review is mainly for external marketing or executive updates misses the empirical core entirely. Also, confusing the Sprint Review with the Sprint Retrospective by focusing on team process rather than the product itself signals a shallow understanding.

LIKELY FOLLOW UPS: The interviewer may ask how you handle stakeholders who treat the Review as a change request forum, how you measure whether the Review is actually adapting the product, or what you do when the Increment is not fully Done. They might also probe how the Review changes at scale with multiple teams or how you balance transparency when the news is bad.

ONE CONCRETE EXAMPLE: Imagine a team built a new checkout flow. Instead of clicking through slides, they show the live analytics and let the support lead try a refund on the spot. The support lead hits a dead end. The group inspects the flow, realizes the refund path was omitted, and the Product Owner adds a high priority backlog item immediately, shifting the next Sprint's focus. The session ends with an updated forecast, not applause.