No Points for Bugs

To start this post, I want to share a bit of dialogue between two characters in the 1987 movie The Princess Bride after their repeated attempts to foil the main character (in this case, after cutting a rope he was climbing).  This esoteric reference  demonstrates how completely and throughly a nerd I am and makes a larger point about a common metric used with Scrum Teams – velocity.

Vizzini: HE DIDN’T FALL? INCONCEIVABLE!

Inigo Montoya: You keep using that word. I do not think it means what you think it means.

So why this quote from The Princess Bride?  Recently, I came across a discussion on the Certified ScrumMasters LinkedIn Group about should a Team estimate the defects.  As it turns out, there was a concern that if a Team did not point (or estimate) their bugs, then their velocity would “look bad”.

When I hear people using velocity like this, I think immediately of Vizzini from The Princess Bride – you use that word –  velocity – but you don’t know what it means.  Velocity is concept from Extreme Programming and is simply an empirical observation of how much estimated work a Team completed within an iteration (or Sprint).  It is nothing more.

It is my opinion that the Team receives NO points for defects.  Alan Shalloway correctly points out that bug fixing is nondeterministic – it is nearly impossible, before working on a defect, to estimate it.  According to Alan, and I agree with him, most of the time spent in fixing a defect is normally spent reproducing and identifying the location of the defect.  This cannot be known in advance, therefore how can we expect Team members to estimate a defect?  Sure – you could estimate it in advance, but the number is pure garbage.

If you read some of the comments on LinkedIn, what really concerns me is the desire by the Team to play with velocity to please management.  Once the Team starts to do this, we have an example of Scheer’s Law and it is time to say good-bye to velocity.

For instance, If a Team had a velocity of 21,341 in Sprint  #12 and in the next Sprint velocity was 13,768 because they are fixing defects (I use a ridiculous number to point out that a velocity of 20 is no more reliable than a velocity of 20,000,000).  This reduction in velocity is a fact – the capacity of the Team was reduced by nearly 40% because they were working on defects.  To give points to fixing bugs obscures the fact that the product was buggy and there were quality issues.  Or perhaps there something was wrong with the engineering practices.  Or maybe the business did not know how to prioritize.  They are many reasons why and Stakeholders should be aware that velocity decreased 40% in Sprint #13 and they should be told it was due to defects.  Giving points to the defects makes it appear that everything was fine when in reality that was not true.

Finally, there was one other comment that concerned me – the idea one should break apart the velocity into value added and non-value added work.  I think the author of the comment was probably referring to planned work vs. unplanned work since fixing defects is a value-add activity.  I would recommend not breaking out the velocity into a number of different categories since that just invites Scheer’s Law.  Velocity was ALWAYS meant to be an easy-to-understand metric that required little or no explanation.  If you start to break down the velocity into all these made-up categories, then it diminishes the power and clarity of the metric and we are back to talking about EVM – using metrics to show the appearance of delivering value.  Metrics should encourage trust and visibility, not the opposite.