Where does accountability lie when acceptance criteria miss the user problem?

WHAT THIS TESTS: This question probes your understanding of empirical process control, the accountability boundaries within a Scrum Team, and the difference between output (meeting acceptance criteria) and outcome (solving user problems). Interviewers want to see that you know the Product Owner is accountable for maximizing value but that the entire Scrum Team is responsible for inspecting and adapting the process. They also want to know if you treat the Sprint Review as a genuine feedback loop rather than a demo.

A GOOD ANSWER COVERS: First, accountability is shared but differentiated. The Product Owner orders the Product Backlog and is accountable for value, yet the Developers are responsible for raising concerns during refinement and Sprint execution, and the Scrum Master fosters the environment for honest inspection. Second, the Sprint Review is the designed inspection point for exactly this scenario. The team should use the Review to inspect the increment against the product goal and adapt the Product Backlog immediately. Third, process adaptations should include three specific changes: rewriting Product Backlog items as problem hypotheses with measurable outcomes rather than just acceptance criteria; inviting real users or stakeholders to the Sprint Review instead of only internal demos; and adding value-validation steps to the Definition of Done, such as user outcome metrics or lightweight usability checks. Fourth, the team should shorten feedback loops by decomposing work into smaller increments that can be validated earlier within the Sprint.

COMMON WRONG ANSWERS: Blaming the Product Owner alone ignores the Scrum Team's collective ownership of the process. Blaming the Developers ignores the Product Owner's accountability for ordering the right work. Suggesting exhaustive upfront requirements analysis contradicts Scrum's empirical foundation and its assertion that knowledge comes from experience. Proposing that the Scrum Master write better acceptance criteria is a red flag because the Scrum Master does not own the product or the backlog. Saying the team should work harder to meet the existing criteria misses the point that the criteria themselves were misaligned with user needs.

LIKELY FOLLOW-UPS: The interviewer may ask how you would measure value if acceptance criteria are insufficient. They might ask what you do if the Product Owner refuses to adapt the backlog after the Review. They could also ask how to prevent this during Sprint Planning, or whether the Definition of Done should include user validation.

ONE CONCRETE EXAMPLE: Imagine a team delivers a search feature that meets all AC: query returns in under 200 milliseconds and supports three filter types. During the Sprint Review, five users explain they actually need to export results to CSV for downstream analysis. A strong response is to recognize the Review worked correctly as an inspection event. The Product Owner immediately reorders the backlog to prioritize export functionality. The team then adapts its process by adding a user problem statement and success metric to every future PBI, requiring at least one user or proxy to attend the Review, and capping refinement discussions with a five-minute check on whether the proposed solution actually solves the stated problem.