Handling bugs with Scrum

28 Oct, 2007
Xebia Background Header Wave

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.


Get in touch with us to learn more about the subject and related solutions

Explore related posts