Changing Scope Mid-Sprint: Consequences and Conversations
This tests your grasp of the Sprint Goal's immutability vs. the Sprint Backlog's flexibility. A good answer assesses impact on the Sprint Goal, then negotiates trade-offs with the PO, like swapping an item of equal size. A red flag is a rigid 'no'.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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?"
Interview question
A Product Owner requests adding a new, high-priority item to the current sprint. What is the most appropriate initial response from the Developers?
- a.Calculate the remaining story points to determine if the team has enough capacity to absorb the additional work.
- b.Assess if the new item jeopardizes the Sprint Goal, and if not, negotiate removing an existing item of comparable size.Correct
- c.Immediately decline the request, stating that the Sprint Backlog is immutable once the sprint starts.
- d.Accept the new item and add it to the Sprint Backlog, as the Product Owner has the final say on priorities.
Why? this is the answer
The correct approach involves first assessing if the Sprint Goal is at risk. If not, the Developers should collaboratively negotiate changes to the flexible Sprint Backlog by swapping items of similar size to maintain focus. Simply checking capacity (A) or passively accepting (D) risks the Sprint Goal and team focus, while a rigid refusal (C) misunderstands Scrum's adaptive principles.
Just read this? Test yourself on what you have been reading.
Read the original → scrumguides.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles