Stakeholder rejects a completed feature in Sprint Review. Process and Backlog impact?

What's really being asked

This question probes your understanding of empiricism, the purpose of the Sprint Review, and the Product Owner's exclusive accountability for ordering the Product Backlog. The interviewer wants to know if you see the Review as an inspection and adaptation event or as a stakeholder sign-off gate, and whether you confuse stakeholder satisfaction with the Definition of Done.

The full answer

First, the Sprint Review is the formal event where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog going forward. The feedback is valuable empirical data, not a failure or rejection. Second, if the Increment met the Definition of Done, it is still Done; the stakeholder gap is new learning about what is most valuable, not a quality defect or escaped bug. Third, the Product Owner collaborates with stakeholders and Developers during the Review to understand the delta between what was built and what was envisioned. Fourth, the Product Owner orders any new or refined Product Backlog items to address the feedback, making trade-offs transparent against existing work. Fifth, the current Sprint is not extended and the Sprint Backlog is not reopened; timeboxes are respected and the team moves to the next Sprint with a clearer forecast.

The mistakes people make

Saying the team should extend the Sprint or add the rework to the current Sprint violates the timebox and misunderstands forecast versus commitment. Claiming the feature is not Done and must be fixed immediately confuses acceptance criteria with the Definition of Done. Saying the Scrum Master decides what to do or overrides the Product Owner usurps the Product Owner's accountability. Ignoring the feedback until the next Sprint Planning misses the adaptation opportunity the Review is explicitly designed to create.

What usually comes next

How would you prevent this mismatch before the next Sprint? What is the difference between acceptance criteria and the Definition of Done? How do the Scrum pillars of transparency, inspection, and adaptation apply here? What if the Product Owner believes the built feature matches the original request?

A concrete example

Imagine a team delivers a new user registration flow. The stakeholder expected social-login options, but the team built email-only registration because the Product Backlog item was ambiguous. In the Sprint Review, the team inspects the Increment, acknowledges the gap, and captures social login as a new Product Backlog item. The Product Owner orders it near the top based on stakeholder value. The email-only Increment remains Done. The team then inspects their refinement process to improve transparency before the next Sprint.