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.

4 Answers 4


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.

  • What would you do if there was simply a misunderstanding, e.g. the team thought an item meant one thing while the product owner meant something else, assuming the items are of roughly equivalent size? This has actually happened at my work before, so it's not purely a theoretical question...
    – Maltiriel
    May 23, 2012 at 21:38
  • 3
    To add on to what Loki answered; you should be in discussion with your Product Owner about any changes to the Sprint backlog, because the team made a commitment to the PO for work to deliver. And if a story was understood incorrectly then the story can be amended to better describe the problem and business value and even be re-sized if enough changed. But always discussing it with the Product owner. Jul 23, 2013 at 11:53

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.

  • 1
    Hmm, that does help, especially your point about people not being clear about stories/items vs. tasks. However, I was wondering not only about adding new tasks, but also about changing/replacing them, such as in the event of a misunderstanding between the team and the product owner. I never have been able to tell what the "best practice" for that is, so if you have any input on that it would be appreciated.
    – Maltiriel
    Jan 14, 2014 at 22:05

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.

  • "during the planning, it is assumed, that everyone clearly knows and discusses about each of the features that they would be working on" Sure, and usually everything works out, but everyone involved is human, so sometimes things slip through the cracks. It's those cases I've been wondering about, because so many people seem so adamant that the sprint backlog can't be edited at all during a sprint under any circumstances.
    – Maltiriel
    May 23, 2012 at 21:26
  • :) Yes we are humans. And sometimes, you will need to make changes during a sprint. But if it keeps happening time and again, there's something wrong elsewhere. May be try talking to everyone about this, and then come up with a mutually agreed solution. May 24, 2012 at 2:11

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.

  • "I agree with the answers, I'd point out that if the story has begun development then it cannot be stopped until done." - that's not true. A team can decide to not finish a story item. Once sprint planning for the next sprint has started, there's nothing requiring them to pull that story into the next sprint. I do really like this statement though: "quality comes from focus and bugs come from dropping a train of thought" Jul 18, 2018 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.