Changing Scope Mid-Sprint: Consequences and Conversations

WHAT THIS TESTS: This question tests pragmatism and collaborative skills over dogmatic rule-following. The interviewer is checking if you understand the core purpose of Scrum's events and artifacts. A junior candidate might say "you can't change the sprint." A senior candidate understands that the Sprint Backlog is a flexible plan in service of the immutable Sprint Goal. Your ability to partner with the PO, explain trade-offs, and protect the team's focus and the sprint's objective is what's being evaluated.

A GOOD ANSWER COVERS: A strong answer is a collaborative conversation, not a confrontation. It covers four key points in order: first, acknowledge the request and seek to understand its value. Second, immediately assess if the change endangers the Sprint Goal. The Scrum Guide states the Sprint Goal is an immutable commitment for the Sprint. Third, if the goal is not at risk, the Developers negotiate the Sprint Backlog with the Product Owner. Since the backlog is a forecast, adding new work requires removing existing work of a similar size. Fourth, make the costs transparent, including context-switching overhead, wasted effort on any now-abandoned work, and the risk to the forecast.

COMMON WRONG ANSWERS: The most common red flag is the DOGMATIC NO: stating "The Sprint Backlog is locked, we cannot make changes." This shows a rigid misunderstanding of Scrum's adaptive principles. The second major red flag is PASSIVE ACCEPTANCE: agreeing to add the work without discussing trade-offs. This signals a lack of ownership from the Developers, leads to burnout, and undermines the purpose of a Sprint Goal by creating a high risk of failure. Finally, an answer that only discusses story points but ignores the Sprint Goal misses the entire strategic point of the sprint.

LIKELY FOLLOW-UPS: Expect follow-ups like: "What if the PO declares it's a critical emergency and insists?" A good response involves making the consequences crystal clear. This might mean recommending the PO and Scrum Team consider cancelling the sprint, which is a serious and rare event, but it's the correct procedure if the Sprint Goal becomes obsolete. Another follow-up is: "Who has the final say?" The Developers own the Sprint Backlog and have the final say on what they can accomplish within a sprint; the PO has the final say on the Product Backlog and its ordering.

ONE CONCRETE EXAMPLE: Imagine a 2-week (10 day) sprint. On day 7, the PO wants to add a 5-point story. The team has a velocity of 40 points and has completed 25. You can say: "To add this 5-point story, we need to remove a 5-point story we haven't started yet to protect our Sprint Goal. If we remove Story X, which we've already spent 8 hours on, that work is lost and our forecast is at risk. A better trade would be removing Story Y, which is also 5 points but hasn't been started. Does that work for you?"