I was recently re-reading the XP books and in Extreme Programming Installed1 I came upon a section where the authors say that bugs should be estimated and planned into iterations like other stories. I disagreed with that idea, thinking about how ‘opinion had changed’ on that topic since the book was written and that ‘that’s not how I was taught to do it’.
Then I wondered why I thought that, just who had taught me that bugs should not be estimated. At first I assumed it was Jim Shore from The Art of Agile2, but a quick look in the book3 shows that he says to estimate bug stories. That led me to do some looking around the Internet4 and discuss this issue with my colleagues at Cyrus Innovation5.
I know believe I have the definitive answer to the question of whether or not to estimate bugs.
(First a clarification: I am not talking about defects found during an iteration in, or caused by, stories being worked on during that iteration. That just means that story is not done. Don’t take credit for it and create a bug card. Just accept that the story is not done.)
And now for that definitive answer:
Some teams might find it useful to give the Customer the ability to prioritize bugs along with other work. By estimating the bugs the Customer has all the data they need to make their trade-offs. That being said: estimating bugs can be very difficult since there is often more than the usual share of unknown unknowns; thus the estimate will be less reliable than normal.
Some teams might find it useful to estimate bugs so that planning an iteration is easier. If a team knows it can do 14 points of work, then 14 points of work can be taken off the top of the backlog, maybe they are all bugs, or some bugs or no bugs; doesn’t matter - it is 14 points. If bugs are not estimated then maybe the team can do some bugs and how many more points? shrug.
Some teams might find that estimating bugs allows the number of bugs to be hidden among the work being done. They want to make sure that bugs are always visible, so they do not estimate want to make sure that bugs always detract from their velocity. Estimating bugs makes them a bit more normal and thus less visible.
So ultimately, as with any such question, the answer depends upon the needs and desires of the team. Do what works for you, and periodically question why and even try a different way.
(Drink Pairing: I paired the writing of this post with a simple Daiquiri6.)
My copy contains the note: “To Mark - Here’s to sucking less! Jim Shore” ↩
Specifically the World Wide Web section of the Internet. ↩
1.5oz Rum, .75oz Lime Juice, .25oz Simple Syrup. Shake over ice ↩