Modifying sprint backlog during the planned sprint

Scrum is a good thing, no doubt, and the Scrum mindset isn’t unreasonable. As we live in the age of agile business environments — always changing, and always adapting — adapting to change is Inevitable. Scrum is a great framework that believes in responding rapidly to changes in the business request, and one of the factors that made Scrum famous is the ability to adapt to changes. In this post, I would like to dig a little more about controlling changes during the current sprint.

Problem background

According to the Scrum guide, ONLY the Development Team could modify the Sprint Backlog. The concern is, the Development team has planning to plan the capacity of them to do, when they re-negotiated with Product Owner, it means that they will see their capacity could do it or not. However, in the actual work environment, sometimes there are situations that in the urgent case Product Owner would like to want the Development Team could add 1 more product backlog into sprint backlog to implement it which won’t 1) endanger the Sprint Goal and 2) decrease the Quality Goal. For the Scrum Master and the Development Team, this could be a challenge as it would negatively affect the progress of the Sprint, especially changing the priority of sprint backlog items.

Solution

Regarding the Scrum Guide (November 2017), “As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.” and “Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.”

The related parts of the Scrum Guide do not specifically refer to user story, but the Scrum Guide used the word “work”. If we assume that the purpose of the work is the same user story, then the modifications (add/remove) do not endanger the Sprint Goal, meaning teams may add or delete user stories.

On the other hand, the word “re-negotiated” is the key point. If the Development Team thinks like there is too much work left to take on additional Product Backlog items in the Sprint Backlog, they should compromise to get anything withdrawn to satisfy the request of the Product Owner. In comparison to being pushed by the Product Owner or someone else, Scrum is a pull system, whereby the Development Team pulls work through its sprint backlog. If they believe that without any other changes to the Sprint Backlog, the additional request can be accommodated, then it is only a decision about whether they want to take it on. This allows for effective inspection and adaptation because it keeps the Development Team in a position to refuse to take on additional work, particularly if it is at risk of achieving the Sprint goal. In the middle of a sprint, the Sprint Backlog items must not be changed, except that something far-reaching emerges in the occasional circumstance that cannot wait until the next sprint. However, it is up to the Development Team to decide if they can take on more work.

It must be remembered that it may be complex to control the Burn-Down chart by modifying the user story to the current sprint. The Burn-Down chart is a practice that can be used by the team to see if they are still on track to achieve what they planned. If a new forecast is made, then the Burn-Down chart represents the new status. If the Burn-Down chart is used for reasons other than the internal progress tracking of the team, then it might be necessary to explain the sudden modification.

Finally, if this happens repeatedly, the Scrum Team needs to talk about this in the retrospective meeting to find out how they could prevent this. Maybe the reason is that:

1. Is the Development Team taking on too much work at the start of the sprint, to begin with?

2. Is the Scrum Team in need of training?

3. Was there too much stuff unclear when the work started?

Please share your thoughts with me on this.