Product Owner wants to change Sprint Backlog scope mid-sprint

WHAT THIS TESTS: This question probes your understanding of empiricism inside the Sprint container, specifically how adaptation interacts with the plan the Developers are executing. The interviewer wants to see if you know that the Product Owner orders work into the Product Backlog while the Scrum Team turns a selection of that work into an Increment during the Sprint, and that changing scope mid-Sprint is not automatically forbidden but must be handled through transparency, inspection, and adaptation.

A GOOD ANSWER COVERS: First, the candidate should state that the Sprint Backlog represents the team's current plan for the selected work, and that the Product Owner does not unilaterally change it during the Sprint. Second, the candidate should explain that because Scrum is founded on empiricism, new learning can justify adjustment, so scope may be renegotiated if the team and Product Owner inspect the change together. Third, the candidate should note the consequences: adding scope risks the Increment and the agreed goals by introducing variance that has not been inspected, while removing scope may require adjusting the materials being produced. Fourth, the conversation should be collaborative, with Developers and the Product Owner inspecting the impact on the current Increment and deciding whether to adapt the plan based on what is observed.

COMMON WRONG ANSWERS: A major red flag is stating that the Product Owner can simply add or remove items from the Sprint Backlog without team agreement, which ignores that the selection of work is a team commitment for the Sprint. Another red flag is declaring that scope can never change mid-Sprint; this contradicts the empirical nature of Scrum where knowledge comes from experience and decisions are based on what is observed. A third red flag is focusing only on velocity or story points rather than the integrity of the Increment and the agreed goals.

LIKELY FOLLOW-UPS: The interviewer may ask how this situation differs from the Product Owner reordering the Product Backlog, which is their prerogative at any time. They may also ask what happens if the change makes the entire Sprint plan obsolete, in which case the team should inspect whether the process or materials being produced must be adjusted or whether the Sprint should be cancelled. Another follow-up is how the Scrum Master fosters an environment where this conversation happens transparently rather than through escalation.

ONE CONCRETE EXAMPLE: Suppose the team selected work to build a payment integration during the Sprint. On day three the Product Owner learns that the provider API has changed and wants to swap the original endpoint for a new one. The Developers should not simply refuse because the item is in the Sprint Backlog; instead, they should inspect the change with the Product Owner, assess whether the new endpoint endangers the agreed goals or the Increment they are building, and adapt the plan if the deviation is within acceptable limits. If the new scope is larger than expected, they may need to adjust the materials being produced or negotiate removing another piece of work to preserve transparency.