Are Defects Anti-velocity?

I've heard this question from so many teams that I thought I would include in a quick post.  The questions revolves around how to account for defects in velocity.  Should they be included in velocity?  Maybe the answer is yes, and no.  It really depends upon what you are trying to measure.

On the one hand, for estimation purposes, defects should absolutely be estimated, prioritized, and delivered just like any other story, backlog item, or feature.  In this case, defects simply represent another type of work being performed during and iteration, and should definitely be accounted for.  At the end of each iteration, regardless of the type of work I am doing, I want to understand the amount of work being performed each iteration.  Even if I am bundling several bugs under a single item, the estimate is critical in properly accounting for the teams projected and actual workload completed during an iteration.

On the other hand, there is also value in understanding the amount of work allocated to functional or feature-based value as opposed to fixing defects during each iteration.  This data by itself is valuable.  In this case, I may want to know how much of the iteration's velocity went to adding real business value and how much went to fixing previously delivered business value (or maybe more appropriately, making up for previous business value never fully delivered).  In this case, the time spent on defects may actually be preventing me from spending time delivering business value -- i.e., an anti-velocity of sorts.

Of the teams we talk to, some teams simply measure feature-specific velocity, with defects serving as a 'necessary' overhead, and many others absolutely include defects and their estimates within velocity.  If you are going to work on something during an iteration, it is probably worth at least attempting to estimate during iteration planning.  These estimates often help drive the priority (i.e., delivering the biggest bang-for-the-buck).  I'd reiterate that the answer may revolve around what you are trying to measure, but the more a team understands about the type of value being delivered during an iteration, the better.

Comments

[David Starr]

I would propose that defects should not be measured as part of velocity. If we protect the sanctity of our trunk code and work to a zero-defect standard, we can absorb defect fixes as part of ongoing work.

It costs more upfront to work this way, but can often times be worth it.