Just the other day I was asked what I initially thought was a simple question: “How do you triage bugs in a personal project?” In typical fashion, I over analyzed it, but outlined a system that met the questioner’s needs.
In a larger, client-driven project triaging is fairly simple: You have defined milestones, client priorities, sprints, and pre-requisites. All of these combine, to a certain extent, to make prioritizing one bug over another mostly straightforward. While some of these exist in smaller, personal projects, they often overlap in strange ways that prevent easy categorizing.
As a result, I look at each bug using the three I’s:
- Immediacy: How easy is it to hit the bug?
- Impact: How severe is the fallout?
- Incidence: How often does the bug happen?
Each of these is a sliding scale. For instance, a crash that happens on startup about 50% of the time has high immediacy (you can’t avoid it), impact (it’s a crash), and moderate incidence (only occurs half the time).
Compare that to a timeout bug that happens every time you navigate pages while waiting for a control to load. We have low immediacy (you likely won’t navigate pages after activating a control so long as it’s responsive), moderate impact (a timeout bug should let the app function after error handling), and high incidence (it happens under these criteria every time).
I’m pretty sure everyone would agree the first example is the priority bug. But, even in the case of two crash bugs, using the three I’s lets me quickly rank two bugs against each other for defining my work order.