A home-robot company's firmware team enters Sprint Review having finished only two of the four Product Backlog items it selected, and the Sprint Goal was not fully reached. The Product Owner wants to skip discussing the shortfall and only demo the two finished items. What should happen at this Sprint Review instead?

The Scrum Guide describes the Sprint Review as a working session where the Scrum Team presents the results of its work to key stakeholders, including what was accomplished and what was not, so progress toward the Product Goal can be discussed and the Product Backlog adapted accordingly. Transparency about the shortfall is the input that makes the rest of the event useful — hiding it removes the very information adaptation depends on. Rescheduling the Review until everything is finished misreads the event's cadence: the Review happens at the end of every Sprint regardless of outcome, and delaying it to manufacture a clean result breaks the Sprint timebox for no real benefit. Quietly presenting unfinished work as though it were complete misrepresents the Increment; only work meeting the Definition of Done can be shown as Done, and blurring that line undermines the empirical basis stakeholders rely on to inspect real progress. Skipping the event altogether treats a missed goal as nothing worth discussing, when a shortfall is often the most valuable thing to surface — it is exactly the kind of signal that should reshape near-term priorities. A concrete check: after any Sprint Review, confirm the Product Backlog was actually updated to reflect what stakeholders learned, not just what was demoed.