Handling Mid-Sprint Scope Change Requests

WHAT THIS TESTS: This question tests your deep understanding of core Scrum principles, specifically the distinction between the flexible Sprint Backlog and the immutable Sprint Goal. Interviewers are looking for your ability to navigate a common, real-world conflict. They want to see if you can uphold the Scrum framework to protect the team's focus and predictability, while also being a collaborative partner to the business (represented by the Product Owner). It's a test of negotiation, prioritization, and adherence to process.

A GOOD ANSWER COVERS: A strong answer follows a clear, collaborative path. First, acknowledge the PO's request and seek to understand the business driver behind it. Second, the Developers assess the request's impact on their ability to meet the Sprint Goal. Third, if the change is small and doesn't endanger the goal, the Developers negotiate with the PO, typically by swapping an item of similar size from the Sprint Backlog. Fourth, if the change is large and invalidates the Sprint Goal, the team explains this consequence clearly. They should present the options: either add the new work to the Product Backlog for a future Sprint, or the PO can make the decision to cancel the current Sprint if the goal is now obsolete.

COMMON WRONG ANSWERS: A major red flag is an immediate "no." This is confrontational and ignores the PO's valid business concerns. Another red flag is an immediate "yes" without assessing the impact. This leads to scope creep, missed Sprint Goals, and developer burnout. A less obvious mistake is treating the Sprint Backlog as completely fixed after Sprint Planning. The Scrum Guide allows for clarification and negotiation as more is learned, as long as the Sprint Goal is not endangered. Finally, candidates who don't mention the PO's authority to cancel the Sprint are missing a key, albeit rare, mechanism for handling major strategic shifts.

LIKELY FOLLOW-UPS: Expect follow-ups like: "What if the PO insists, even if it endangers the Sprint Goal?", which tests your ability to involve the Scrum Master to facilitate and uphold the framework. Another is, "How do you quantify the 'size' of the change to negotiate a swap?", which probes your experience with estimation techniques like story points or cycle time.

ONE CONCRETE EXAMPLE: "The PO asks to add a new payment provider integration mid-sprint, which is a 5-point story. Our Sprint Goal is to 'Improve checkout conversion by 5%.' We're currently working on 20 points of work aligned with that goal. We'd explain that adding a 5-point story means we must drop another 5-point story, which would put the Sprint Goal at risk. We'd recommend adding the new provider to the top of the Product Backlog for the next Sprint. If they say it's a 'must-ship-now' legal requirement, we'd explain that this invalidates our current goal, and the correct Scrum action is for them, the PO, to cancel the Sprint so we can immediately plan a new one around this new priority."