Apr. 9, 2016

Velocity and the Zero Point Bug, What Do You Think?

I had an opportunity to attend a training class recently, and someone I admire, dismissed the practice of giving bugs 'zero' points as, flat out 'Wrong'.

I have worked with several teams that embrace velocity as pure mean to manage the backlog (long term planning) and when bugs are identified, they track those bugs as zero point items for a number of reasons.

1) The teams took credit for velocity when a new item was pulled into a Sprint. Period. If a bug is identified, then they didn't do the work correctly, which showed up downstream as a bug, they don't want to take credit for doing the same work twice.

2) By showing a reduced capacity within the sprint (shorter term - release planning) they also use this as a trigger - an opportunity to review and evaluate the TYPE of bug they are working, to determine if there is a larger - refactoring opportunity they need to explore - ultimately in order to recoup capacity which will allow them to work on new features (velocity).

I feel like this meets the criteria of 'measuring the right thing' and hey, if the team buys in and it aids in their ability to improve, how can this be wrong?

My own takeaway - the self organizing team should discuss what works for them - understand the 'why' and inspect/adapt. If it helps the team grow their quality practices, and increase value, I consider it 'right'.

Interested in your thoughts.