One Way to Handle Mid Sprint Scope Changes in Scrum

The Scrum Guide doesn’t directly address how to incorporate scope changes into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. What I mean by scope changes is a material change to an existing Product Backlog Item(PBI), or an emergency last minute PBI. The strategy(chart) below is one I’ve developed as a result of coaching teams that are new to Scrum.

I hope you don’t need the chart. I’ll say it again. I hope you don’t need the chart below. I hope that you have so few late breaking PBI’s and material scope changes that you don’t even really need to worry about having a strategy to handle mid sprint scope changes. But, for the teams that need some guidance on how to incorporate these occurrences into their Scrum implementation, see below for one way to approach it. I also feel compelled to say that if you find yourself needing this strategy/chart often, you probably have some serious root cause analysis and retrospecting to do on these occurrences. I’m not saying these occurrences will always be a bad sign, just that many of them probably could have been prevented by better practices elsewhere.

On the other hand, if the late breaking changes are really a result of great customer collaboration and delighting customers, that could not have been prevented ahead of time, then it might fall into the category of “not a problem — just adjust and move on.” While we don’t want constant requirements churn, we also need to be open to last minute customer collaboration, which often can only occur once the customer can see the functionality in the UI. If you’re getting customer collaboration mid sprint, in addition to at the Sprint Reviews, then you’re already ahead of the game and probably doing good collaboration. Remember these Agile Manifesto value statements… we value “Customer Collaboration over Contract Negotiation” and we value “Responding to Change over Following a Plan.”

Regardless of the late breaking change, adjust first, then be sure to retrospect as to the root cause. If the root cause turns out to be “We had a great discovery with our customer mid sprint that could not have been predicted”, then figure out how to have more of that, not less of that! Don’t try to be 100% predictable. On the other hand, if the root cause turns out to be “We could have prevented this with better collaboration ahead of time, or better Product Backlog Refinement,” or something else, then do an experiment to see if you can prevent that kind of late breaking churn in the future.

If your scope change is due more to existing weird behavior in the system (possibly a bug or other production support issue), then use the Bradley Bug Chart instead.

If your scope change is enormous, and possibly makes the vast majority of current Sprint work moot (such as a re-org or company buyout, or some other major event), then read the text in the Scrum Guide to see if “cancelling the Sprint” is applicable. Note that cancelling a sprint is an extremely rare occurrence — see the Scrum Guide for more on that.

I fully expect that each team will define their own strategy for handling this kind of stuff. Remember, this is just an example.

Why I include “Bradley” in the name.

Please be sure and read the “Preface” section on the chart below. You can also download an 8.5″ x 11″ PDF version here instead: ScopeChange4-2

I welcome any feedback you might have, as like all things Scrum, I expect to inspect and adapt it again after receiving feedback. You can email me by putting Charles in front of @ScrumCrazy.com .

To potentially be addressed in the next version of the chart:

• (Major, Important) — Add language to include the most recent update to the 2013 Scrum Guide about not “endangering the Sprint Goal”
• (Major, Important) — Update language to reflect the 2013 Scrum Guide (esp Grooming/Refinement, etc)
• Change the name of the chart to “The ScrumCrazy.com Scope Change Chart”
  • After this change is complete, we will need a corresponding article change here: Why I include “Bradley” in the name.
  • After this change is complete, keep a link to the previous version as PDF.
• (Minor important) — Consider expanding this chart to include any kind of mid sprint scope interruption — including collabing with others in org on stuff that is not pertinent to the current sprint scope.
• (Minor – Nice to have) — Consider improving the language on retrospecting to include requirements churn, excellent customer collaboration.