It’s a common theme on SCRUM teams: How do we account for bugs? You never know how many will come in, what will be their priority, and what about those fifty or so that have been sitting in the backlog forever? I’m happy to share my experience and my process for turning around a project and eliminating bugs as they pop up. First, you need to define your bug priorities. I don’t mean “Blocker” or “High,” but rather concrete definitions of what constitutes a particular bug severity. Here’s what I use:

• Blocker: Anything that prevents main feature use with no workarounds, or anything that corrupts data
• High Priority: Anything that prevents main feature use with no obvious workaround, or anything with major UI/UX problems
• Medium Priority: Anything that prevents feature usage but has an obvious workaround, or any minor UI/UX problems
• Low Priority: Minor annoyances and minor UI/UX issues

Second, you need define an SLA (Service Level Agreement) for each bug — that is, what is your time commitment to fixing the bugs. Here’s what I use:

• Blocker: 24-hour SLA
• High Priority: 1 Sprint SLA
• Medium Priority: 2 Sprint SLA
• Low Priority: 2 Sprint Review

So, Blockers must be fixed within 24 hours. Sometimes a blocker can’t be fixed in that amount of time, but the goal is to look at Blockers above any other Sprint work and to fix them ASAP. After all, they are corrupting your data or prevent the use of your product! Now that you’ve defined a common methodology for determining the priority of a bug, and you’ve committed to fixing them within a specific time frame, the third thing is to define time in your Sprint for taking care of the bugs. I do this with two stories, appropriately prioritized in the Sprint.

• As a Developer, I have time to fix Blocker bugs.
• As a Developer, I have time to fix bugs.

That’s the Sprint backlog. Blocker bugs are added directly to the Sprint below the first Blocker Bug story and are worked on as soon as they come in. In JIRA, bugs aren’t point-estimated, so they don’t affect the Sprint velocity. That’s fine because your Blocker Bugs story already affects Sprint velocity. To track the amount of work on bugs, after estimating those two stories just like any other story, add Tasks for each developer:

• As a Developer, I have time to fix Blocker bugs.
  • Matt: 10 hours
  • Jerry: 10 hours
  • Nyle: 10 hours

As you work on bugs, update the time remaining for the task. If I spend 5 hours on a bug, I’ll have 5 hours of capacity remaining. In this way, you can accurately track how much time you spend on bugs and appropriately point the Story the next time. On one project, we assigned 2 points for this story and about 6 points for the second story. Over time, the Blockers Story was reduced to 1 point and the non-blocker Story went down to 2 points. We eliminated over 100 bugs in the backlog over the course of 3 or 4 sprints, and we were left with only the few that came in during a sprint. As a Product Owner, you must always monitor the backlog for new bugs and immediately review and prioritize them. If they are incomplete, you need to ask the creator to fix the bug. You’ll get duplicates; eliminate those. Prioritize them both with the Priority setting and by moving them up the backlog. The backlog gives you an infinite number of priorities rather than just the 4 buckets mentioned above by simply changing the order of the bugs. There are two more special Story types for taking care of bugs. First, when a Story is accepted, it must pass specific acceptance criteria, and there may be problems encountered during Product Owner or QA testing of those criteria. Often a story is useful for tracking the time used to fix those types of issues:

• As a Developer, I have time to fix Acceptance Criteria bugs.

Treat this the same as the others — with tasks and time estimates. This type of story is especially useful when QA occurs out of the Sprint cycle — i.e., when QA tests your stories during the next Sprint. If testing occurs within the Sprint, then you can just account for this time in the original Story and just add a task for bug fixes. The second special Story type is for bugs that have sat in the backlog for more than 2 Sprints. The review of bugs that are older than 2 Sprints can have several outcomes: you might decide it needs to be fixed, or perhaps it will be obsolete after the release of a new feature. If you decide it needs to be fixed, then create a special Story for fixing just that bug:

• As a Developer, I have time to fix TICKET-1234.

Name the specific bug and point the Story as you would any other Story in the Sprint, accurately accounting for the time needed to perform the fix. With this process, you should be able to accurately account for the time needed to fix bugs and eliminate your backlog of issues. Keep on top of new bugs as they come in and the quality of your product will just get better and better. Need help with QA and testing on your mobile app? Don’t worry, we’ve got you covered. Give us a call or contact us online to learn how we can help you.