Two Types of Bugs

Two Types of Bugs

June 27, 2008 | Development, Preferred Practice, Scrum

A bug is a bug is a bug, right? Not so!

Most development shops treat a bug as a task. That seems reasonable – it’s a bit of work that needs to be done. Unfortunately, it’s not so easy. If a bug is discovered in a feature that is currently under development, and it will be fixed in the current Sprint (iteration), then the bug can and should be treated as a task. It would be considered a new Sprint Backlog Item that must be closed before the feature can be considered “Done”. However, if the bug is not fixed before the feature is considered “Done” (yes this really happens), or the bug is discovered after the feature has be deemed “Done”, then the bug becomes a bit of work to be scheduled into a future Sprint. In other words, the bug should be treated as a Product Backlog Item.

The rule of thumb is rather easy really. If the bug is going to be fixed in the current iteration, then treat it as a task. If not, then the bug needs to go on the product backlog and be prioritized right along with all the other Product Backlog Items.

Of course, this raises the question: What does “Done” mean exactly? Many dev teams grapple with this deceptively simple question. I’ll explore this question in a future post.