Confused about modifying the sprint backlog during a sprint

Question

I've been reading a lot about scrum lately, and I've found what seem to me to be conflicting information about whether or not it's ok to change the sprint backlog during a sprint. The Wikipedia article on scrum says it's not ok, and various other articles say this as well. Also my Software Development professor taught the same thing during an overview of scrum.

However, I read Scrum and XP from the Trenches and that describes a section for unplanned items on the taskboard. So then I looked up the Scrum Guide and it says that during the sprint "No changes are made that would affect the Sprint Goal" and in the discussion of the Sprint Goal "If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint." It goes on to say in the discussion of the Sprint Backlog:

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

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. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

So at this point I'm altogether confused. Thinking about it, it makes more sense to me to take the second approach. The individual, specific items in the backlog don't seem to me to be the most important thing, but rather the sprint goal, so not changing the sprint goal but being able to change the backlog makes sense. For instance if both the product owner and the team thought they were on the same page about a story, but as the sprint progressed they figured out there was a misunderstanding, it seems like it makes sense to change the tasks that make up that story accordingly. Or if there was some story or task that was forgotten about, but is required to reach the sprint goal, I would think it would be best to add the story or task to the backlog during the sprint.

However, there are a lot of people who seem quite adamant that any change to the sprint backlog is not ok. Am I misunderstanding that position somehow? Are those folks defining the sprint backlog differently somehow? My understanding of the sprint backlog is that it consists of both the stories and the tasks they're broken down into.

Anyway I would really appreciate input on this issue. I'm trying to figure out both what the idealistic scrum approach is to changing the sprint backlog during a sprint, and whether people who use scrum successfully for development allow changing the sprint backlog during a sprint.

Answer 1

First of I would not have hard rules about it; the whole point of scrum is to allow you to adapt to the situation. So you should be able to modify the sprint backlog during the sprint if you absolutely must (like you forgot something critical).

But saying this modification to the sprint backlog during the sprint should be resisted. The whole point of the sprint being short is that new work can be added to the next sprint (after it has been correctly prioritized) without affecting the overall project timeline (multiple sprints).

But if the work is critical for one of the tasks in this sprint you have two options.

1. Add new item to the sprint.
   BUT remove an equivalently sized item from the sprint.
2. Drop the item that was badly planned from this sprint (so you can properly plan it in the next sprint).
   • Adding in an alternative (of appropriate size) from the top of the product backlog (which should have be in priority order from your sprint planning meeting).
   • Or when all sprint items are finished allow dev's to pick up slack from the product backlog.

So I am in the camp that you should probably not modify the sprint backlog. But you have to take into account the situation there may be exceptional circumstance. In most cases I would go with options 2 and let devs pick up the slack with tasks from the backlog.

Then in the next planning meeting the new task will be appropriately analysed and added to the sprint (as appropriate).

Remember the sprint is short and just the mark of the next drop not the end of the development cycle. The product owner would have to be very desperate for a feature that they could not wait for the end of the next sprint.

Answer 2

The confusion is due to ambiguous language.

The Sprint Backlog has two levels of detail. First, it is a list of Items (User Stories) that the Team has committed to deliver. Second, it is all the TASKS that the team intends to do in order to deliver each of those stories.

So when people talk about the Sprint Backlog, they should really be clear about what they mean. When you read the Scrum Guide you'll see that it states: The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

So it is BOTH the list of Product Backlog Items AND the Plan (Tasks) to deliver them.

Now, many teams like to add all the proposed tasks (plan) at the beginning of the Sprint so they can track a burndown chart based on hours left to do. Other teams let the tasks emerge as required. THIS is when it's OK to add to the 'Sprint Backlog', since the team has to do that in order to inspect and adapt in order to deliver the Items and meet the Sprint Goal.

Under certain circumstances, a team may be well-ahead of schedule and (having eliminated all other useful tasks that could improve the Team's capabilities) may decide to work with the Product Owner to select another story (should already have been prioritized and sized) from the Product Backlog... but only if they have the confidence that it will be completed within that Sprint and that it aligns with the Sprint Goal.

So, there we have it; YES... teams DO add Tasks to the Sprint Backlog plan as required. NO, they don't usually add to the list of Backlog Items that define the Scope of the Sprint.

I hope this clarifies the situation.

Answer 3

It depends on your situations. If some information is missed out during planning, and then later you figure out that you need to modify or add some points to a few stories, then I think it's fine. But, yes, if the scope of a feature changes completely, then thats an extreme situation, and needs to be handled differently.

But of course, during the planning, it is assumed, that everyone clearly knows and discusses about each of the features that they would be working on. If the discussions and planning is good, then in almost all the cases you don't really need any modifications.

Answer 4

I agree with the answers, I'd point out that if the story has begun development then it cannot be stopped until done.

Dig your heels in early on. Those asking for the change will have to learn the hard way, else you end up with planning being worthless if people learn you can do what you like anyway.

Cite that quality comes from focus and bugs come from dropping a train of thought. Cite the cost of context-switching. Tracking debt and the management of writing and discussing and playing-in a story to address half-baked work is costly. Just don't start down this route.

Idea: give management 3 switch-credits to spend each quarter as a compromise.