At Sprint Review for the parks pavilion-booking Increment, a recreation supervisor says the new fee calculator will cause more phone calls, not fewer. A deputy director wants the Product Owner to defend the Increment and keep the supervisor out of future Reviews. What should the Product Owner do?

Negative Sprint Review feedback is learning to inspect against the Product Goal, not a reason to exclude stakeholders. When a recreation supervisor says the new pavilion fee calculator will cause more phone calls—not fewer—and a deputy director wants the Product Owner to defend the Increment and keep the supervisor out of future Reviews, the Product Owner should treat the feedback as learning and adapt the backlog. Excluding the supervisor from future Reviews so negative comments stop reduces transparency and hides risk. Reverting the Increment immediately without discussion may be premature if evidence is still thin, and it skips collaborative inspection. Asking the Scrum Master to mark the Review as failed so the team feels the cost of criticism weaponizes the event. Exam caveat: not every complaint is correct, but suppressing critics is incompatible with empiricism. Operational check: capture the phone-call hypothesis, measure contact rates after the fee calculator release, reorder backlog work if evidence supports the supervisor, keep the stakeholder in Review, and adapt without performative blame. Keep civic stakeholders focused on inspectable outcomes for residents and operators rather than inbox politics or vanity metrics.