Don’t Confuse a Bug’s Priority with Its Severity

In app development, not all bugs are created alike and not every bug in your app deserves to sip the precious nectar that is developer time. Yeah your app is crashing, but if it only happens when someone clicks on the read more button under the app developer’s bio, then ask yourself: is it really that important? Or conversely, what about that rogue comma floating in the 2nd line of your welcome screen? Does that warrant a last minute bug fix right before you submit to Apple? Knowing where to focus’ your development team’s effort, in the face of a constant barrage of bugs, such that you minimize risk and maximize delivery is an essential skill if you’re trying to deliver a piece of software, be it app, web site or that batch job running on a 10-year old OptiPlex under your desk.

At Blue Label, we’ve developed over 200 apps and over that time we’ve developed a bug triage process we view each bug through a prism of priority to classify a bug and its importance. The Priority field we use on a JIRA issue answers how important is fixing this bug to the release schedule? Would you release this product even with this bug present? Or is it more of a nice to have, but not a crucial type of thing? At Blue Label, we use a P0-P1-P2 bug prioritization scale , where a P0 (Blocker) bug is a ship-stopper which has to be fixed before the next release can happen. P1s (Critical) are important but not something we’d stop a release for, while P2s (Medium,Low) represent pretty much anything that will only be fixed when our development team has cleared all P0 and P1 bugs.

It’s important to note that a bug’s priority shouldn’t be confused with its severity, which exists as an entirely different dimension. At Blue Label, we use the JIRA field called ‘Severity’ to represent a (somewhat) objective assessment of a bug’s impact to the functionality of the system. From Critical representing major crashes or hangs, to Minor functional issues or purely Cosmetic blemishes. While a QA engineer will classify a bug’s Severity at creation time, it’s the PM who assigns the Priority at the time of triage based on their knowledge of the client’s business and product requirements. Something that is Critical severity doesn’t necessarily mean its a P0. That crashing bug in your bio screen? Face it, nobody really cares to read it and few will ever click the button, so its not something that should be a P0 ship-stopper. Meanwhile, a misplaced comma might seem like nothing worthy of emergent attention, but what if it completely re-purposes your brand statement? That’s as cosmetic as a bug can get, but it is something that might warrant a P0 label given the implications to the business. It’s important to not conflate severity with priority, and to not let the impact of a bug confuse your judgement of its relative importance.

Effective bug triage is an essential hygiene and success factor for anyone managing a software release. Knowing how to look at a bug and then attach a priority to it is the first step in an effective triage process. While knowing how severe a bug is an important data point to weigh, but that alone should never be the deciding factor on how you prioritize a bug.