Sprint Goals met but features don't solve stakeholder problems

WHAT THIS TESTS: This question tests whether you understand that Scrum's definition of success is value realization, not just process compliance. Meeting a Sprint Goal and producing a Done Increment are necessary conditions, but they are outputs. The interviewer wants to see if you recognize that the empirical pillars of transparency, inspection, and adaptation must apply to the product direction and stakeholder outcomes, not just the team's execution velocity. Specifically, they are looking for awareness that the Sprint Review is the primary feedback loop where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog, and that a weak Review renders the team blind to value gaps.

A GOOD ANSWER COVERS: First, diagnose the Sprint Review. If stakeholders are surprised or dissatisfied, the Review may be a demo rather than an inspection event; the team might be showing features without discussing whether they solve the problem. Second, examine Sprint Planning. The team may be selecting Product Backlog items based on capacity or output commitments rather than a clear Product Goal that stakeholders co-created. Third, inspect the Product Backlog ordering. The Product Owner might be prioritizing by feature count or internal deadlines instead of validated learning or risk reduction. Fourth, propose adjustments: invite stakeholders to Planning to refine the Sprint Goal together, define outcome metrics before building, and use the Review to gather empirical evidence rather than sign-offs. Fifth, emphasize that adaptation belongs to the whole Scrum Team and stakeholders; the Product Owner must be willing to re-order or discard backlog items based on what is learned.

COMMON WRONG ANSWERS: A major red flag is suggesting the team needs better requirements upfront or more detailed specifications, which contradicts Scrum's empirical approach to complex work. Another is blaming the Product Owner alone; while the Product Owner is accountable for value, the entire Scrum Team is responsible for inspecting outcomes. Prescribing more velocity, overtime, or tighter deadlines is also wrong because the problem is direction, not speed. Finally, suggesting that the Sprint Goal should be abandoned or that Scrum is failing misses the point; the goal is likely valid, but the feedback loop connecting the goal to stakeholder value is broken.

LIKELY FOLLOW-UPS: The interviewer may ask how you would measure outcome versus output, how to handle a Product Owner who refuses to change priorities, or what to do if stakeholders do not attend the Sprint Review. They might also probe whether the team should stop Sprints to do discovery work, or how to balance long-term Product Goal alignment with short-term Sprint Goals.

ONE CONCRETE EXAMPLE: Suppose the team ships a Done Increment of a new reporting dashboard every Sprint. Stakeholders say it does not help them make decisions. The process failure is that the Sprint Goal was likely something like deliver the dashboard widgets rather than validate that users can find actionable insights in under two minutes. The adjustment is to reframe the next Sprint Goal around an outcome hypothesis, invite three stakeholders to the Review to observe real usage data, and adapt the Product Backlog to deprioritize additional widgets in favor of a simpler export feature that users actually requested during inspection.