Probably the most contentious point in my projects is bugs (aka defects) and how to deal with them. Every new team I work with asks how we’re going to organize, strategize, and resolve bugs. Since they’re a normal part of software development, you can’t ignore them.
Here are are few ways you can make life easier when it comes to bugs.
First things first, lock down your DOD
A solid definition of done (aka DOD) is going to tell you where to begin with bugs. Lock down what it means for a story to be “done” in relation to the bugs in that story. For example, is a story done if it has three bugs filed against it? If those bugs are cosmetic, then my teams might say yes. As a delivery team you need to decide where the severity threshold is in your project. We use the following categories (from least severe to most severe):
– Cosmetic
– Minor
– Moderate
– Major
– Critical
The first bugs to be squashed
The teams I work with usually take all Major and Critical bugs into the current sprint and resolve them. This is probably because the user stories they are linked to won’t pass QA without all Critical and Major bugs first resolved. In other words, stories can’t reach a done state while those bugs are open. That’s in our definition of done so that’s how we operate. If a bug doesn’t fall into this category, we drop it into a separate bucket aptly named “Bugs.”
The Bugs bucket
I didn’t want bugs to get lost in our ever growing backlog, so one day I created a separate JIRA container in my projects specifically for bugs. We found it helpful and have been using it ever since. It allows the team to easily see the list of all logged bugs which aren’t Major/Critical in one spot.
Hold on, this isn’t anywhere in Agile Scrum… OK, so I know we’re diverting from traditional Scrum a bit on this Bugs bucket thing, but let’s be fair; Scrum is a framework, not a process. I think the “Backlog” gets too messy with bugs, stories, improvements, and tasks intermixed. This is especially true when you consider that bugs aren’t recieving story points (usually) and are very different from stories. But how does the team know what the true order of priority is on all backlogged items then? Using the Ready List, the PO can pull top priority items for the next two sprints from the Backlog and Bugs bucket into one place.
Who is responsible for what
There are really only two areas of responsibility on bugs. One falls to the person filing the bug (generally QA) and the other falls to the Product Owner.
The following areas are generally owned by QA:
– Title
– Severity
– Environment
– Issue description
– Steps to reproduce
– Observed result
– Expected result
– Recommended resolution
– Screenshots
– Linked stories
The second area of responsibility falls to the PO and they only have one task:
– Priority. All a PO needs to do is determine what priority that bug should be listed at. This is the order in which the bug will be taken into a sprint to be resolved.
Bug scrubs
Scrubbing bugs is a critical organization technique that I’ve seen work really well. This can be done in a meeting with your PO or as a separate task for the PO to handle alone. Simply put, QA walks the PO through each bug individually and the PO prioritizes them. This is a good opportunity for the PO to ask questions and learn more about challenges the coders are facing. This can be done with or without other team members in the room.
Bug bash: What it’s for and how it’s used
If you need to do some manual testing in a pinch and you’re light on QA staff, a bug bash might be just what you’re looking for. Schedule a 1-2 hour meeting on your team’s calendar and make sure you have devices, builds, and a conference room ready to go. Once gathered, test and logs bugs together as a team (nobody is left out). You’re putting in the equivalent of 10 working hours; an efficient five person team can cover some serious ground.
