How do you adapt when user feedback invalidates your current sprint?

WHAT THIS TESTS: This question tests your senior-level pragmatism and leadership. The interviewer is evaluating your ability to recognize that Scrum is a framework for adapting to change, not a rigid process to be followed at all costs. They want to see you connect a process problem (an invalid assumption) to a business outcome (minimizing waste) through concrete technical solutions. It's a test of ownership beyond simply completing assigned tickets.

A GOOD ANSWER COVERS: A strong answer outlines four steps in order. First, immediate communication. You don't wait for a formal ceremony; you raise the issue and its implications to the Product Owner (PO) and the team as soon as it's discovered, embodying the Scrum pillar of transparency. Second, impact assessment. You collaborate with the PO to quantify the blast radius. Is the entire Sprint Goal obsolete, or just one part of the plan? You should propose concrete options: pivot the work, pause and shelve it, or scrap it entirely. This may lead the PO to negotiate the scope of the Sprint Backlog with the Developers. Third, technical mitigation. This is crucial for a senior role. You should detail how to use feature flags to isolate the in-progress work, ensuring the increment remains potentially releasable. Discuss how a modular architecture makes this pivot cheaper than in a tightly-coupled monolith. Fourth, team re-alignment. Once the PO makes a decision, you help ensure the entire team understands the new direction and that the Sprint Backlog is updated to reflect the change.

COMMON WRONG ANSWERS: The most common red flag is the 'Rigid Scrubber' who says, "We must finish what we committed to in the sprint." This ignores the core purpose of Agile, which is adaptation. The commitment is to the Sprint Goal, and if new information makes that goal obsolete, the plan must change. Another weak answer is the 'Passive Player' who would simply stop working and wait for instructions or the next planning meeting. This shows a lack of ownership. Finally, a 'Process-Only' answer that just says "I'd talk to the PO" without suggesting concrete technical strategies for managing the in-progress code is insufficient for a senior role.

LIKELY FOLLOW-UPS: Expect follow-ups like: "What if the Product Owner insists you continue building the feature anyway?" to test your influence and communication skills. Or, "How would you have architected this feature differently if you knew this assumption was risky from the start?" to test your proactive design thinking. A technical deep-dive might be, "Walk me through the Git strategy you'd use to shelve this work safely."

ONE CONCRETE EXAMPLE: In a project building a new payment flow, we assumed users wanted Apple Pay integration prioritized. Mid-sprint, analytics from a different product showed our target demographic had only 15% iOS adoption. I immediately raised this with the PO. We estimated that 50% of our sprint's work was tied to this. I proposed we wrap the Apple Pay SDK work in a feature flag (off by default) and pivot the remaining sprint capacity to building a more generic credit card form. We salvaged the foundational work but avoided wasting ~25 story points on a low-impact feature, delivering more value by adapting.