During the Sprint Review for the building-permit portal, contractors suggest several adaptations after inspecting the Increment. What should the Product Owner do next?
Select an answer to reveal the explanation.
Short Explanation
The Review is an open kitchen, not a takeover of the stove. Invite the contractors to taste and talk, then the Product Owner still decides the next cook order. Collaboration is input; accountability for order stays in one pair of hands.
Full Explanation
The Sprint Review for a building-permit portal exists so stakeholders can inspect the Increment and adapt the Product Backlog. Contractor suggestions after seeing working software are valuable empirical input, not a transfer of Product Owner accountability. The Product Owner should welcome those adaptations as input, then remain accountable for the resulting Product Backlog order toward the Product Goal and value. Collaboration is input; ordering accountability stays with one person.
Letting contractors vote the new backlog order fails because customer democracy is not Scrum’s Product Owner accountability model. Handing suggestions straight into the next Sprint Backlog without Product Owner ordering fails by mixing Sprint planning ownership and skipping value-based order. Closing the Review without capturing ideas fails because it suppresses inspect-and-adapt and treats the Product Goal as too fragile for customer evidence.
Exam caveat: Sprint Review adaptations inform the Product Backlog; they do not reassign who orders it. Operational check: Capture contractor suggestions in a visible parking list during the Review, then within days publish how the Product Owner ordered, deferred, or declined each theme against the permit Product Goal.