How do you handle negative stakeholder feedback in a Sprint Review?

WHAT THIS TESTS: This question tests your understanding of Scrum's foundational principles: empiricism (inspection and adaptation). The interviewer is checking if you see this scenario as Scrum working correctly—a successful inspection leading to a necessary adaptation—rather than a failure of the Sprint. It also tests your knowledge of the Product Owner's role as the sole manager of the Product Backlog and the purpose of the Sprint Review and Retrospective.

A GOOD ANSWER COVERS: A strong answer walks through five distinct steps. First, acknowledge the feedback as valuable input; the Sprint Review's purpose is to elicit exactly this kind of information. Second, the Product Owner is responsible for capturing the essence of the feedback. The development team does not debate or commit to changes. Third, after the review, the PO works with the stakeholder to refine this feedback into one or more new Product Backlog Items (PBIs). These are new requirements, not bugs, assuming the original work met its acceptance criteria. Fourth, the PO then prioritizes these new PBIs against everything else in the backlog based on value. The new work may or may not be in the next Sprint. Fifth, the entire Scrum Team discusses the 'why' behind the mismatch in the Sprint Retrospective to improve their process, perhaps by creating more interactive prototypes or involving stakeholders earlier.

COMMON WRONG ANSWERS: A major red flag is treating the feedback as a failure or a crisis. Wrong answers include: blaming the stakeholder for changing their mind or the PO for poor requirements; immediately promising to 'fix it in the next Sprint,' which usurps the PO's authority and devalues other backlog items; classifying the feedback as a 'bug' when the delivered work met the Definition of Done, which corrupts metrics; or arguing with the stakeholder during the review, which shuts down the feedback loop.

LIKELY FOLLOW-UPS: Expect follow-ups like, "How could this situation be prevented?" (Answer: Better backlog refinement, interactive prototypes, earlier stakeholder check-ins). Or, "What if the stakeholder is the CEO and demands it be changed immediately?" (Answer: The PO's role is to manage this, explaining the trade-off—e.g., pulling an engineer off the next Sprint's goal, which reduces velocity by X points and delays Feature Y).

ONE CONCRETE EXAMPLE: The team delivers a feature with a blue 'Export' button, as specified in the PBI. In the Sprint Review, the stakeholder says, "Seeing it live, I realize it needs to be green and say 'Export as CSV' to match our new branding." This is not a bug. The PO creates a new PBI: "Update Export button color and text for new branding." The PO then prioritizes this PBI. It might end up as item #25 in a 200-item backlog, scheduled for a Sprint in two months, because launching the new billing page (PBI #1) is a higher business priority.