One Way to Handle Production Support and Bugs in Scrum – Bradley Bug Chart

The Scrum Guide doesn’t directly address how to incorporate production support and bugs into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. 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 bugs and productions support issues arise, that you don’t even really need to worry about classifying bugs or coming up with a technique to handle production support. 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.

For mid Sprint changes in the scope of a Product Backlog Item, or the Sprint Backlog itself, see the Bradley Scope Change Chart.

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:  ScrumBug-613-2.

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

• Change the name of the chart to “The ScrumCrazy.com Bug 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.
• If you find yourself saying “Yes” a lot at step #5, your system is likely very low quality.  While you might assign story points to it, you should keep close track of these “legacy quality” bugs.  If you’re spending a lot of time on issues like this, you likely need to increase the quality of the system by improving your Definition of Done and/or slowing down your  delivery and taking more time for quality.
• Background: Changes related to production support time that do not meet the definition of bug. Examples are prod support time that turn out to be not a bug in the current system under development, or other urgent prod support time(Examples: diagnosing a hardware failure, production support triage/bug reproduction, material research time that ends in no further action, etc) that cannot be tied to a change being made to the current system under development for the current team.
  • In the definition of bug, change “…inconsistent with requirements that…” to something like “…inconsistent with requirements for a system under development by this Dev team that…”
  • Consider a new question before 4A along the lines of “Does the work require a change to a system under development by this Scrum team?” If yes, then go to the current 4A decision. If no, then go to step 7
    • Re-word Step 7 as follows: “…whether it will be fixed in the…” to “…whether the issue will be addressed in the…”
    • Re-word Step 8 as follows: “FIX IT!” to “DO IT!”
• Consider making the “retrospect” blurb more prominent for continuous improvement efforts.
• Consider adding the note from scope change chart on how dev team defines what “material” means
• Consider adding a blurb on how each team will define what is material/immaterial
  • “Each team can define what material/immaterial time means. The term “material”, in reference to size, is a financial accounting term that essentially means “things of immaterial size don’t matter, so spending time worrying about how you will account for them is wasted time.” In a Scrum context, immaterial means “too small to worry about how you’ll track it”, and “small enough that it won’t jeopardize the Sprint forecast and Sprint Goal.”

To potentially be addressed later:

Consider speaking to the “Should I assign story points to bugs” question on the chart, or maybe through a supporting article.