Priority vs Severity: Don’t Confuse Bug Priority With Bug 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?
This is a key time to question bug priority vs. severity and recognize the contrasts between the two. 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. It is especially important to recognize the difference between severity and priority of a bug to avoid wasting your team’s resources.
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.
When approaching the question of priority vs. severity, it’s important to note that a bug’s priority shouldn’t be confused with its bug 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 bug severity with bug 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, and recognizing the difference between severity and priority of a bug is crucial. 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 organize bug priority. Our experience in development gives an acumen in finding and squashing bugs like digital exterminators.