Over the years I have always instructed Agile Team to not point Defects, or Spikes or Technical Debt, etc. Many of us Agile Coaches taught this way, it wasn’t just me. Then along came a blog post by Mike Cohn about recommending pointing Defects (http://www.mountaingoatsoftware.com/blog/should-story-points-be-assigned-to-a-bug-fixing-story LINK). I chewed on this for quite some time because I can see both sides but there was just something about pointing Defects that “stuck in my craw”. And I figured out what it was.
One of the tools used in Agile Development is pain. No, not the ruler on the knuckles kind of pain but pain we inflict on ourselves or is thrust upon us. This kind of pain can be a great motivator. You only have to attend one Sprint Demo and tell everyone in attendance that you have nothing accepted to show them to make you change the way you do things. Similarly, we used the Release Burndown chart to point to what I call “Defect Holes”, places where the consumption of Release Scope was negatively impacted by defect work.
It normally accomplished it’s intended purpose, pointing out the fact that something was going on in the Release so we could attend to it. But it had other consequences. Teams didn’t like the fact that there wasn’t a visualization for this work and that velocity didn’t show this work. They didn’t get “credit”. You can coach a team all day on WHY velocity shouldn’t account for this work but their still not happy.
Mike brings up some very good points especially as it relates to an existing backlog of Defects and Technical Debt. (If you read the short blog post be sure to read the responses from Charles Bradly and David C J Morris as well.) So I can see there are times when pointing non-Release Scope stories may be beneficial. Which got me to thinking, if we could type this work differently and visualize it differently then this could be beneficial all around. Imagine a Release Burndown where the “Defect Holes” weren’t just blank but those work efforts were “sized” and the Release Burnup modified to show the effect.
Which then got me thinking if I could add in another type of work, Quality Improvement Work. Quality Improvements work items help the product even though it doesn’t (usually) change or enhance any functionality. So I changed the Modified Release Burnup Chart again to add it in.
This those that desire to size certain Defects as well as visualizing it’s effect on the Release Burnup Chart. By extension this could also apply to Sprint Burndowns. Additionally, the traditional Velocity Chart would remain what it is and be based on the “light green” bars in the images above but we can also begin to track metrics like Percentage of Quality Improvements in the Release, Percentage of Defects Handled in the Release, etc. It should be noted that there are NO Agile tools that can produce these Modified Release Burnup’s yet but if enough people see value in them, who knows, it just might happen.