How to handle user feedback that invalidates your current sprint's work?

What's really being asked

This question probes your understanding of Scrum's core pillars: transparency, inspection, and adaptation. The interviewer wants to see if you treat a sprint as a rigid contract or as a learning loop. For a senior role, they are specifically testing your proactivity in raising issues, your ability to connect process to technical execution, and your focus on delivering value over just completing tasks. It's a test of agility in practice, not just in theory.

The full answer

A strong answer outlines a four-step process. First, immediate transparency: stop work on the invalidated path and communicate the findings to the Product Owner (PO) and the rest of the development team. Second, collaborative inspection: work with the PO to assess the impact. Is the Sprint Goal itself now obsolete? The Scrum Guide states the PO is responsible for the Product Backlog, but the whole team collaborates. Third, propose adaptive technical strategies: suggest concrete ways to minimize waste. This could involve using a feature flag to disable the partially built feature, creating a separate branch to preserve the work for later, or refactoring the work to abstract any reusable logic. Fourth, support the decision: the PO may decide to pivot the sprint towards a new goal or, in extreme cases, cancel the sprint entirely. Your role is to provide the technical context to help them make the best decision.

The mistakes people make

A major red flag is suggesting you would continue building the feature "because it was in the sprint plan" and wait for the Sprint Retrospective to discuss it. This demonstrates a fundamental misunderstanding of agility and creates waste, which lean principles (a foundation of Scrum) aim to reduce. Another poor answer is to make a unilateral decision without involving the Product Owner, which undermines their role in maximizing value. A junior answer might just say "I'd tell the PO," but a senior answer provides the technical "how" to enable the pivot.

What usually comes next

Expect questions that dig into the technical details. "How would you implement a feature flag system for this?" "Walk me through how you would refactor the code to salvage the useful parts." "What's the threshold for recommending a sprint cancellation versus just pivoting?" "Describe a time you did this and what the outcome was."

A concrete example

"In a previous project, we were building a new checkout flow assuming users wanted a one-click purchase option. Mid-sprint, user testing showed they were confused and wanted a final review screen. I immediately paused my work, which was 70% complete. I raised it in our daily stand-up and with the PO. The Sprint Goal was 'Improve checkout conversion,' which was now at risk. I proposed we put the one-click logic behind a feature flag, a 2-hour task, and then use the remaining sprint time to build the review screen. The PO agreed. We salvaged the work, met the revised goal, and avoided shipping a feature that would have hurt conversion."