I know I know, you shouldn’t have any bugs / all bugs should be fixed during a sprint / if bugs are long lived do you need to fix them? OK, ideally, yes, but back in the real world we’ve all had bugs in our backlogs at some point. Maybe you’ve just rushed out a new client to fulfill a commercial imperative, or maybe that new developer hasn’t quite found his feet yet, or maybe you’ve just worked a 80 hour week and your brain is mush. Inevitably at some point you will find your self estimating bugs alongside stories.
Lets say that your team follows scrum and estimates in story points, you estimate a load of stories, you estimate a load of bugs. You prioritise your backlog and use your previous velocity to forecast the work you can complete in the next sprint.
Now, let me pose two scenarios and a follow up with a question:
A) You have a sprint comprised mostly of bugs, your previous average velocity was 40.
B) You have a sprint comprised mostly of stories, your previous average velocity was 40.
Do you find that the amount of work you’ve allocated to the next sprint is equal in both scenarios A and B?
What I’ve found
In my experience, a team will complete the work in scenario A much more quickly than they will the work in scenario B. Why might this be?
Well perhaps bugs are not good candidates for story point estimation, but then I’ve found that a team can estimate the relative size of one bug against another.
Well perhaps teams are less good at estimating bugs because there is a greater degree of uncertainty, so err higher. Maybe the fear of this uncertainty is greater than the eventual complexity.
In reverse, maybe teams underestimate the level of learning and uncertainty required to implement a story, so underestimate.
Maybe teams find it hard to compare the relative effort of bugs to the relative effort of stories and so mentally use different criteria when allocating a points estimate.
A Proposed Approach
Maybe it’s possible to reasonably estimate both bugs and stories, but maybe the scales on which the points occur differ depending on the subject, a bug or a story. Perhaps it would be worthwhile collecting velocity for bugs and velocity for stories as distinct data points. A bug velocity and a story velocity and then using these to project a work forecast for a sprint.
Only one way to find out….