Team delivers features, but stakeholders are unhappy. Why?

WHAT THIS TESTS: This question probes your understanding of Scrum as a framework for delivering value, not just software. It separates candidates who see Scrum as a set of rituals from those who understand its empirical core: transparency, inspection, and adaptation. The interviewer is looking for your ability to diagnose problems in the feedback loop between the people building the product and the people using it. They want to see if you can identify process failures and propose systemic improvements, rather than blaming individuals.

A GOOD ANSWER COVERS: A strong answer methodically investigates several potential failure points. First, the Sprint Review: is it a genuine working session to inspect the Increment and adapt the Product Backlog, or just a one-way demo? Second, the Product Goal: is there a clear, overarching objective guiding the Sprints, or is the team just tackling a list of features? Third, the Product Owner's role: is the PO effectively representing stakeholders, prioritizing the backlog based on value, and available to the team? Fourth, the Definition of Done: does it include any form of value validation, or just technical completion?

COMMON WRONG ANSWERS: A junior answer focuses on outputs. They might say, "The team is meeting its goal, so it's a stakeholder problem" or "We need to write better user stories." These are red flags. Another common mistake is to suggest solutions without diagnosing the problem, like "We should do more user testing." While potentially correct, it's a leap. A senior candidate first identifies why the need for user testing was not caught earlier. Blaming the Product Owner without suggesting how the team can support them is also a weak response. The worst answer is to suggest increasing velocity, as this only accelerates the creation of low-value features.

LIKELY FOLLOW-UPS: "Let's say the Product Owner is overwhelmed and not available. What can the team do?" (Answer: The team can help by refining backlog items, developers can pair with stakeholders, the Scrum Master can coach the PO). "How would you change the Sprint Review to make it more effective?" (Answer: Invite real users, structure it around the Sprint Goal, use interactive formats, focus on adapting the Product Backlog). "How would you measure whether your proposed changes are working?" (Answer: Track stakeholder satisfaction, user engagement metrics, or qualitative feedback over the next 2-3 Sprints).

ONE CONCRETE EXAMPLE: "In a past role, our team shipped a new reporting dashboard that met all acceptance criteria. At the Sprint Review, we learned stakeholders found it confusing and it didn't answer their core business questions. We were hitting Sprint Goals but missing the mark on value. We adjusted by changing our Sprint Review format from a demo to a hands-on workshop with stakeholders. We also insisted that every major feature have a 'value hypothesis' attached. This shifted our planning from 'build this report' to 'help the sales team identify their top 10 leads in under 60 seconds,' which led to a much better product."