Handling Negative Feedback in a Sprint Review

WHAT THIS TESTS: This question isn't about a single correct action. It tests your fundamental understanding of Scrum's empirical pillars: transparency, inspection, and adaptation. The interviewer wants to see if you recognize the Sprint Review as the primary event for this feedback loop. They are also testing your understanding of the Product Owner's role as the sole person responsible for managing the Product Backlog and ordering work. A senior candidate should see this not as a failure, but as Scrum working as designed.

A GOOD ANSWER COVERS: A strong answer outlines a calm, process-driven response. First, actively listen to the stakeholder's feedback without getting defensive; the goal is to understand the gap between their vision and the delivered increment. Second, emphasize the Product Owner's role in facilitating this conversation, collaborating with the stakeholder to understand the 'why' behind the feedback. Third, explain that the outcome is not a 'bug fix' but new work. This new work is captured as new or updated Product Backlog Items (PBIs). Fourth, state clearly that the Product Owner is responsible for ordering these new PBIs in the backlog based on value, risk, and dependencies. They may or may not be worked on in the next Sprint.

COMMON WRONG ANSWERS: The biggest red flag is promising to fix it in the next Sprint. This undermines the Product Owner's authority and the entire purpose of backlog ordering. Another wrong answer is to treat the feedback as a 'bug' against the original requirements; if the team built what was asked, it's not a bug, it's a new requirement or a clarification. Blaming the stakeholder ('You should have told us sooner') or the Product Owner is also a major red flag, as it shows a lack of collaborative spirit and misunderstanding of shared discovery. Finally, a weak answer is just 'we'll add it to the backlog' without explaining the PO's role in ordering it.

LIKELY FOLLOW-UPS: 'How could you prevent this from happening in the future?' (Answer: Earlier and more frequent stakeholder engagement, better user story mapping, more robust Definition of Ready, prototypes). 'What if the stakeholder is very senior and demands it be fixed now?' (Answer: The Product Owner handles this, explaining the trade-offs of disrupting the plan and the value of other items in the backlog. It's about making the cost of the change transparent).

ONE CONCRETE EXAMPLE: Imagine we delivered a new user management screen. The stakeholder says, 'This is wrong, I can't bulk-disable users.' The team built it according to the story, which only specified adding and editing single users. The Product Owner would say, 'Thank you for that feedback. The ability to bulk-disable is a great idea. Let's talk about how that would work.' They then create a new PBI: 'As an admin, I want to select and disable multiple users at once so I can efficiently manage organizational changes.' This PBI is then sized and ordered in the backlog. It might be worth 8 story points and land three sprints from now, after more critical work is completed.