Our software has bugs. We fix most of our bugs.
So far our team probably sounds a lot like yours. Where we may begin to differ is in how we go about deciding which bugs to fix and how we signal to ourselves that we need to focus on bugs above other forms of valuable work.
Exposure: Another view on bugs to fix
Many of us have worked on teams where bug triage decisions involve lots of conversations around the severity and priority of each bug. For some reason though, these measures leave a lot to be desired. If I had to guess, I’d say this is because the purpose of the triage is to set priority. So it may be easier to have a conversation around factors that influence the priority rather trying to tackle priority head on.
A mental model that has worked well for us is to think of bugs the way that PMs usually think of risk: through the lens of risk exposure[1]. The most common tool here is the risk matrix (or probability and impact matrix). When our team wants to make decisions about which bugs to fix first, we focus our conversations on the probability that a customer will encounter the bug and the impact to that customer should they encounter the bug. Admittedly, the values we use are qualitative, but thinking about our bugs in this way allows us to have much more effective conversations that lead to a final determination around priority. So rather than debating about priority head on, we use two proxy measures that allow us to reason about the priority: probability and impact.
Here’s a recent bug matrix:
Every two weeks we revisit our bugs to make sure we’re working on the most important defects in our product. We arrange our bugs on a matrix where impact is along the horizontal axis and is quantified as Low, Medium or High. Likelihood of occurrence is arranged on the vertical axis as Unlikely, Sometimes or Very Likely. Once we reach agreement on the general impact and likelihood of each bug we end up with a matrix where the bugs we want to fix first are generally in the upper right area of the matrix and the bugs we may defer or simply not fix are located in the lower left area.
Don’t ignore your bugs
Since bugs are, in part, a reflection of the quality of our product we know that we shouldn’t ignore them. Above I mentioned that every two weeks we triage our bugs. What I should have said is, we intend to triage our bugs at the start of every iteration (2 weeks for us), but we sometimes fall short. Conflicting schedules and priorities sometimes cause us to miss these meetings. When that happens it’s nice to have a reminder that we’re being delinquent. Enter the bug alligator chart:
The bug alligator chart is a term I picked up from a QA Manager I once worked with. The general premise is to keep a track of open and closed bugs. This chart tends to look like the opened mouth of an alligator when the open bugs outpace the closed bugs. An open mouth alligator is dangerous. We want the alligator’s mouth to be closed. I’m not sure that the chart always looks like an alligator but it is helpful to see the trends of all opened bugs to closed bugs. In the bug chart above there was a period where we weren’t closing any bugs but new bugs were being discovered. Seeing that the gap between our opened bugs and our closed bugs was trending in the wrong direction was a strong signal that we needed to have another triage session to get the right bugs added to our development queue.
We’ve been using the bug exposure matrix and alligator chart for a few months now on the Mingle team. While the most important thing no doubt is that we have regular conversations about our bugs, we’ve found that shifting the way we prioritize our bugs has led to much easier conversations.
[1] See “Waltzing with Bears” by DeMarco and Lister