Handling bugs with Scrum

28 Oct, 2007

On my current project, we are using Scrum to build a data processing and publishing application. Our aim is to deliver working, tested software each sprint. Our team includes testers that test the software we make, as we make it. Any bugs they find we try to resolve as soon as they are discovered. Sometimes, though, bugs can not be resolved in the sprint in which they are found. These bugs must be dealt with using the Scrum process.
We use the following process for this. At the end of a sprint, all unresolved bugs classified by the testers as major or higher are entered onto the product backlog as separate items. Issues of minor importance are collected in our bugtracking tool. At the planning meeting for the next sprint, the product owners select the highest priority items (including bugs) from the product backlog for inclusion on the sprint backlog. Items that are not selected remain on the product backlog, possibly for next sprints.
This process provides transparency about the workload left to the product owners, both in terms of user stories to be developed as well as outstanding issues. They can decide on the relative priority of these, giving them full control over the sprint scope. It also creates a bridge between our issue tracking system and the Scrum process, ensuring that these are not two separate worlds.
For this to work it is critical that the testers and the product owners agree on what constitutes a major versus a minor bug. If this is not the case, either unimportant issues show up on the product backlog (and will most likely remain there) or, worse, important issues are left in the minor category, with no visibility to the product owners. A regular review of minor issues with the product owners mitigates this risk and provides further transparency to stakeholders.

Newest Most Voted
Inline Feedbacks
View all comments
Lars Vonk
14 years ago

Hi Martin,
Nice read. I like the fact that by putting the bugs on the product backlog you keep it visible.
I have one remark / question though: Would you say that you calculate to little time for testing? If after every sprint bugs are found maybe it is a sign of some miscommunication or flaw in the process. To quote my colleague Machiel Groeneveld: “If a bug is found it is both the developer and testers fault, they did not communicate in advance what is going to be tested”. Is there enough communication in the team?
Cheers, Lars

Ron Thijssen
Ron Thijssen
14 years ago

Hi Martin,
I think this is a good approach. But there’s this question running through my mind right now.
Do you consider user stories that still have bugs finished? In other words, can a user story be completed with still having bugs? Do you create new engineering tasks per bug, or are it different user stories? Sometimes bugs can take up to weeks to be solved and that will greatly influence your velocity.
Greetz, Ron

Martin Schapendonk
14 years ago

Hi Martin,
I tend to disagree with you (also see Ron’s comment) to count a story as finished when there are still major bugs. It seems like you need a different definition of done.
What would happen if the story wasn’t considered done and you discussed it with the team at the retrospective?
(another) Martin

Alberto Brandolini
14 years ago

Hi Martin(s)
I am trying to figure out the boundaries between a Product Backlog and an issue tracking system. In some cases looks like the two systems overlap but this fusion never works well… looks like some of the reasons are emerging here:
– Product backlog are larger scale items. Although you can put them in an issue/bug tracking system an Excel spreadsheet is more suitable for reprioritizing and planning.
– bugs must be closed ASAP. This makes the expected lifetime of a bug (maybe in my dreams) shorter than an iteration. Only few complex bug can make it to the product backlog to become part of the following iteration. Making this an exception ensures quality.
– “Who does what” is not a top priority. Assigning bugs is not so interesting in SCRUM. You have the daily meeting, and the team is self organizing.
– as a result a bug tracking system has a reduced scope in SCRUM, lives basically within a single iteration, and allows feedback from external remote users, etc…

Explore related posts