Scope changes in a sprint

It’s important for a sprint to be predictable. As stated in earlier posts on new teams, there is the issue of how to create good estimates, and a focus on completion. But one of the problems is how to deal with bugs and those critical fires, especially if the organization prides itself on customer support and responsiveness.  I’d like to give a few basic principles.

• Nothing gets done unless it is a task in the sprint and shows up in the burndown
• For a task to be added, it has to meet one of the following criteria:
  1. It’s a task that was not anticipated for an existing story, and would be added to that story.
  2. It’s something truly new: there should be a new story and a new task under that story.
• All changes in scope (new stories) are under the control of the product owner.

Simply stated, no task gets added to the work to be done in the sprint without it being associated with a story. If it’s an increase in the scope of the sprint, the product manager has to decide this and the team must accept the change in scope in the sprint.  Of course, we can anticipate a certain amount of these and have a budget for bugs and pressing. But we can also decide to just put this bug in the backlog for the next sprint. My view is that you’d be surprised at the number of things that can wait two weeks if you can tell someone that you definitely will look at it then. Most people want immediate responses because it’s easier to ask for that than it is to have to follow up when you don’t have faith that the other part will execute without your badgering.

The key is that every change is a deliberate decision. The product owner decides to change the scope of the sprint. And the scrum team decides to take it on. Or the scrum team decided that the size of the existing story was larger than expected, based on improved knowledge.

There are numerous articles and charts on how to deal with this:

• One way to handle Bugs and Production Support in Scrum
• Handling scope changes mid-sprint
• On changing requirements mid-sprint

My preference is to never change the scope in a sprint. But, as we have to make changes, let’s be deliberate.

And my preference is that if something gets to step 8 and tasks are added, you should be creating a story to go with it so that you can have a predictable velocity. And avoid these interruptions as much as possible.