Handling bugs with Scrum

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.

Comments (6)

  1. Lars Vonk - Reply

    November 1, 2007 at 11:30 pm

    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

  2. Martin van Vliet - Reply

    November 2, 2007 at 12:02 am


    I agree with you that this situation is relatively rare if there is good communication between the developer and tester. However, we are building a Swing GUI on our project and find that regression bugs appear quite more frequently than in server-side code because the GUI code is much harder to test automatically. These bugs are the main reason we use this process.

  3. Ron Thijssen - Reply

    November 8, 2007 at 4:31 pm

    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

  4. Martin van Vliet - Reply

    November 11, 2007 at 8:00 pm

    Hi Ron,
    good question. We count the user story as finished (and include the points in the team's velocity for the sprint) if there are no implementation tasks left for the user story.
    The issue itself, if major, becomes a new user story. The complexity estimate of the new story reflects how hard it is to solve the bug, so if we expect it to take two weeks, then this will reduce what new functionality we can pick up in that sprint.

  5. Martin Schapendonk - Reply

    November 22, 2007 at 3:14 pm

    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

  6. Alberto Brandolini - Reply

    December 17, 2007 at 5:15 pm

    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...



Add a Comment