Who's accountable when an increment fails the user?

WHAT THIS TESTS: This question tests a senior candidate's understanding of Scrum as a framework for empiricism and adaptation, not a process for assigning blame. The interviewer wants to see if you default to finger-pointing or if you see this as a systemic failure. The core test is whether you recognize this as an opportunity for the entire team to improve its feedback loops and shared understanding of value, demonstrating a grasp of collective ownership.

A GOOD ANSWER COVERS: First, shared accountability. While the Product Owner is accountable for maximizing product value via the Product Backlog, the entire Scrum Team is accountable for creating a valuable, useful Increment. This includes Developers, who must be engaged enough to ask "why" and challenge assumptions, not just build to spec. Second, root cause analysis of the process. The problem isn't just a bad user story; it's a failure in the process of discovering what is valuable. Third, specific process adaptations. Propose concrete changes like improving Product Backlog Refinement by involving developers in user interviews, creating lightweight prototypes for in-sprint validation, or adding a mandatory 'User Goal' field to tickets. Fourth, frame this as Scrum working. The Sprint Review successfully made the value-disconnect transparent, enabling the team to inspect and adapt.

COMMON WRONG ANSWERS: Blaming the Product Owner: "The PO wrote bad acceptance criteria. It's their fault." This shows a junior-level, siloed mentality and ignores the Developers' role in seeking clarity. Blaming stakeholders: "They signed off on it and then changed their minds." This deflects responsibility and confuses meeting criteria with delivering value. Vague solutions: "We need better communication." A senior candidate must provide specific, actionable process changes, like "We will dedicate 10% of our Sprint capacity to backlog refinement activities, including direct Q&A with the user researcher." Forgetting the Retrospective: Not mentioning the Sprint Retrospective as the formal event to inspect and adapt the team's process is a major omission.

LIKELY FOLLOW-UPS: How would you facilitate that Retrospective to ensure it's productive and not a blame session? What if the Product Owner is resistant to developers getting more involved in discovery? Give me an example of a time you've seen this happen and what your team did.

ONE CONCRETE EXAMPLE: A team built a data export feature that met all ACs: CSV format, correct fields, and filters. At the Sprint Review, the user revealed they needed to import this data into a legacy system that only accepted a fixed-width text file. The feature was technically correct but useless. The process failure was assuming the 'what' (a data export) without understanding the 'why' (to feed a specific downstream system). The fix was to add a 'User Problem' section to every story and have a developer join the PO in a 15-minute sync with the requesting user before starting work on any major feature.