Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


The first thing about handling scope changes mid-Sprint is to recognize what type of scope change it is.

Bug or Production Support request?

If it's a bug, or a production support research request, then my preferred method is to use One way to handle Bugs and Production Support in Scrum . As it says in that article, I hope you don't need that chart. If you're one of those teams where such bugs and production support requests are very rare (say, on average, once or less every 2-3 months), I'd say just do it and you can choose whether to make it a Product Backlog Item or put it on the Sprint Backlog. You'll probably lean towards PBI if it's a big thing, or put it on the Sprint Backlog if it's a small thing.

Scope Change to PBI in Progress

If it's a scope change to a Product Backlog Item in progress, my hope is that this means a new or changed acceptance/story test of some sort. If you're not practicing Acceptance Test Driven Design, you should be! For you non ATDD types, the old school terminology for this is a "requirement change." I've been around the block a few times coaching Scrum Teams on this scenario. My best advice is this:
  • If the sum of all changes in scope this sprint, for this specific story, is likely to increase the originally estimated size for the story by more than about 10%, then the changes should be a new Product Backlog Item by themselves. You may need the whole Scrum team to re-estimate to determine if the 10% threshold has been met. Remember, estimating is a whole team sport!
  • If the sum of all changes is less than about 10%, then just change your acceptance tests, do it alongside the current PBI, and move on with life.

Swapping in the new PBI

If the scope change does result in a new PBI, then in rare cases where it is strongly warranted, a Scrum Team should be flexible enough to swap that PBI in and do it in the current Sprint. However, this usually means some other PBI will have to be swapped out of the Sprint as well. If these kinds of "swaps" begin happening regularly, then your team needs to do a root cause analysis on the swaps in the Retrospective.
  • In this scenario, don't forget that the new, urgent PBI needs to be groomed, sized, and tasked out on the Sprint Backlog. Get all of your team together and you can usually do this in a matter of minutes.

I discuss this topic more in One Way to Handle Mid Sprint Scope Changes in Scrum .

coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg