Handling bugs in Scrum

I'm sure the title of this post would make a few Scrum zealots heads spin, steam coming out of their ears, etc. However all the agile TFS templates have Bug work items, implicitly acknowledging that most teams would need to use them. So how do bugs fit into a Scrum process? I'll start off by appeasing the zealots saying that in an ideal world we wouldn't raise bugs in a scrum project. PBIs should be sufficiently small and well groomed for the team to build, test, and mark them as done within the sprint boundaries. If any discrepancies are found during the sprint they should just be reworked and retested. It's not worth raising bugs for work in progress.

However, if bugs are found relating to code that was marked as Done in an earlier sprint then a Bug can be created in TFS to schedule and track the fix of the bug in a future sprint. Note that it is worth making sure that the Bug is not just an enhancement in disguise (if so it should be raised as a PBI). One principle of agile is to have a potentially shippable code base at the end of each sprint. This doesn’t necessarily mean the code has to be bug free – many bugs have acceptable workarounds, which can be managed through user training / documentation. Therefore bugs raised do not automatically get added to the next sprint, though reviewing the current bug list is always a good place to start during sprint planning. So a bug in one sense is just another PBI in the backlog which can be prioritised up or down along with the rest.

Should Bugs be given story point estimates? There are two arguments here. Firstly a genuine bug indicates that we need to perform so rework on code we previously had considered to be complete. Therefore every bug should be assigned a 0 point value since we’re not really delivering any more functionality and having a point value would taint our project data (make us look more productive than we really are).

On the other hand, regardless of whether developers are working on bugs or PBIs we still want to be able to measure their velocity from sprint to sprint – how much work, on averge, can be completed in a sprint. We can also measure the total points for PBIs vs Bugs to give an indication of rework and a prediction of future rework for the incomplete PBIs in the backlog.

My recommended approach is to give all Bugs point estimates in the same way as PBIs (and using the same relative scale) but to be aware when calculating metrics such as hours per story point that the bug story points should be removed from this calculation (but the hours to fix the bugs included).

Also, since Bugs are generally smaller pieces of work compared to PBIs it is sometimes worth setting a minimum value on PBIs when initially estimating the backlog to leave ‘room’ for some smaller Bug estimates later – e.g. all initial PBIs are estimated at 3 points or above. The alternative is to group a number of bugs together (usually ones relating to the same feature/page/component) to make a larger PBI, but I dislike this approach since it prevents bugs from being prioritised separately.