An often asked question is how does Scrum recommend a team to handle bugs? Should they be placed on the product backlog? Or on a separate bug list? If they’re on the backlog, does the Product Owner get to set their priority or are they automatically the most important items? Should there be a separate bug fixing sprint?
On Pascal Maugeri’s team, even after improving their definition of done and doing “proper testing/unit-testing”, they’re still finding bugs that escape the sprint. He asks how to resolve this problem.
George Dinwiddie, Agile Coach, suggests raising the issue with the team during the retrospective – he has worked with teams that had vanishingly small bug rates. Mark Levison (this reporter) suggested “I would start to ask the question why weren't they found and fixed within the sprint that they occurred? My focus is on reducing the time it takes to discover (and then fix) problems. After all, if we discover a bug in the story during the sprint it is written then the PO shouldn’t accept it as being done. In addition early discovery will make it much easier to fix as the code is still fresh in the mind of the development team.”
Jim Schiel, CST with Artisan Consulting, just puts bugs in the product backlog to be prioritized by the Product Owner - “unless it’s a dead simple fix, in which case you determine the solution during Sprint Planning and execute the solution during the Sprint.”
Bruce Kantelis says it’s all about developing a culture: “We categorize defects. Priority 1, blocking the user from working get immediate attention, the interrupt work for a fix and patch, all others become stories that are placed at the top of the list for the next sprint. Over time, teams realize that quality measures and behaviors really impact their workday and rally to minimize the interruption.”
Mike Cohn reminds us that bugs found within the sprint are best handled by yelling across the team room and describing the bug. Failing that, a card describing the bug can be added to the board. However for bugs that escape the sprint – he prefers to add them to product backlog, leaving it up to the product owner to prioritize them. Many existing teams still have a bug database that they need to continue using. In that case, he counsels maintaining a separate bug backlog, where product owner simply says what his priorities are from each queue: i.e. the first two items from the product backlog, then the following bugs and finally the next two items from the backlog.
Kevlin Henney argues that this approach is akin to treating a bug as a feature with a negative value:
If defects are viewed as features with negative value, they become managed as if they were features. Development groups store up prioritized repositories of bugs, treat bugs as user stories, outsource the fixing of bugs, and so on. While each of those can be a useful technique or perspective in dealing with a project in transition or crisis, it is not a long-term view that should be encouraged. After all, as the "Manifesto for Agile Software Development" says, "Working software is the primary measure of progress." It is a little disingenuous to pass off a feature with known defects as complete and working — "Yes, it's done... but there are a few bugs."
Ron Jeffries turns the whole problem on its ear saying that fixing a defect in a feature after it's finished is always more expensive than doing it right the first time.
So when we write the software incorrectly and then fix it, the customer pays more: she pays whatever she paid before, plus the bug fixing penalty.
She should be really ticked off about that. I like to encourage the customer to prioritize all the defects, to ensure that she'll feel the pain of the team's inadequate software process. I feel sure that she'll express that pain and that the team has a better chance of getting the idea that doing things well is better.
Do you avoid bugs altogether? Put them on the Product Backlog? Do you see the problems Kevlin outlines?