How do you adapt in-progress work when feedback invalidates a key assumption?

WHAT THIS TESTS: This question tests whether you understand Scrum as an empirical framework built on transparency, inspection, and adaptation rather than a rigid plan. The interviewer wants to see that you treat a Sprint as a container for learning, not an immutable contract, and that you can pair process discipline with technical tactics to reduce waste.

A GOOD ANSWER COVERS: First, process behavior: you make the feedback visible immediately to the Product Owner and Developers because low transparency makes inspection misleading and adaptation wasteful. You inspect the impact together, and if the invalidated assumption threatens the Sprint Goal, you renegotiate the Sprint Backlog with the Product Owner or even cancel the Sprint if the Goal becomes obsolete. Second, technical strategies: you describe feature flags to hide invalidated paths without deleting working code, modular design or branch-by-abstraction to wall off the affected component, and incremental delivery so only validated slices are merged to trunk. Third, waste reduction: you emphasize preserving the stable parts of the increment, using automated tests to guard unaffected modules, and treating the invalidated assumption as a learning signal rather than a personal failure.

COMMON WRONG ANSWERS: A major red flag is saying the team must finish the original plan because the Sprint is locked; Scrum has no rule preventing scope renegotiation between the Product Owner and Developers when the Goal is threatened. Another red flag is bypassing the Product Owner and unilaterally changing priorities, which breaks transparency and trust. Saying you will simply work overtime to rebuild everything also signals poor risk management and ignores lean thinking.

LIKELY FOLLOW-UPS: The interviewer may ask how you would measure whether the Sprint Goal is truly threatened versus merely uncomfortable, how you would communicate the change to stakeholders expecting the original scope, or which code patterns you use to make rollback cheaper. They might also probe whether you would still demo the partially invalidated increment at the Sprint Review.

ONE CONCRETE EXAMPLE: Suppose you are building a checkout flow based on the assumption that users want one-click purchasing. Mid-Sprint, usability tests show users distrust one-click and want an explicit confirmation step. You immediately flag this in the Daily Scrum, the Product Owner agrees the Sprint Goal of reducing cart abandonment is at risk, and you renegotiate the Backlog to swap the one-click epic for a two-step confirmation flow. Technically, you wrap the one-click logic behind a feature flag, keep the shared cart and payment modules untouched, and use branch-by-abstraction to route traffic to the new confirmation path once it is ready. The increment remains integrated and deployable throughout.