LookFar Labs9 February 2017
Defining Priority and Severity: How to Classify and Approach Product Issues
Focusing on what matters for your users
Opportunity cost is the inevitable truth that no matter what you do, you’re foregoing your ability to do the next best thing. Software development follows that truth in a big way; if you have two issues in your software but only have the resources to address one, the other is going to get put in the backlog.
So how do you determine which one needs fixing?
By identifying Severity and setting Priority. These two criteria allow tech professionals to take a more objective approach to software maintenance and focus on the biggest issues that matter to you and your users.
Severity: How Bad is it?
Severity can be answered by asking, “how serious is this?” In the medical field, an issue with minor severity could be thought of as a hangnail or a small cut, while a head or spinal injury would be a critical issue. When we’re talking about software, severity of an issue is more objective, and can be determined by measuring the impact it has on your product’s functionality.
There are three classifications of Severity: Critical, Major, and Minor.
Critical: an issue that results in complete loss of functionality and has no workaround.
Examples: Your program crashes. Your website displays errors and no content.
Major: Part of your application or software doesn’t do what it’s specifically designed to do; there may be a workaround.
Examples: Your reports calculate incorrectly. The dates of your event are inaccurate.
Minor: Non-critical functionality of your software is affected, and the issue may have a workaround.
Examples: Navigating away from a page clears form data. Users can’t edit their profile.
Priority: How Quickly Do We Need to Fix it?
Priority determines where a task ranks in order relative to all the other tasks that need to be completed. Severity needs to be considered when setting priority, but the two are not interchangeable terms. Priority is the measure you’ll use to assign what is most important to get done now and what might be able to wait until later. Priority has the assignments of High, Medium, and Low.
High – An urgent problem that blocks the system use until the issue is resolved.
Medium – A core functionality that your product is explicitly supposed to perform is compromised.
Low – Should be fixed if time permits but can be postponed.
Priority is, most commonly, set initially by software testers or developers. After triaging and reporting, Product Managers or Owners can adjust priority to best suit big picture goals.
Using Severity and Priority in Tandem: Examples of All Combinations
An issue that crashes a site when you have 2,000 simultaneous visitors is definitely a high severity issue. However, if you’re running a small website that only gets a maximum of 20 simultaneous visitors, would it really be the best use of your time/money to fix? Answering these questions with any measure of objectivity becomes a lot easier if you evaluate them through the lens of both priority and severity.
High Priority / Critical Severity:
This type of issue likely affects more than 50% of your userbase in a way that makes it so they can’t use core functionality that your software is designed to perform.
Low Priority / Critical Severity:
This is an issue that inhibits core functionality, but it’s not very likely to occur or it isn’t something your users are worried about as much.
High Priority / Minor Severity:
This issue may not impact functionality, though you’ve decided it’s something that you want to get done soon for a reason that should be clear to all stakeholders.
Low Priority / Minor Severity:
Most likely, this doesn’t impact someone’s ability to use the product, isn’t very serious, and is something that users aren’t very concerned with seeing fixed–if at all.
Now that we’ve covered severity and priority in detail, let’s look at what some real world examples might look like, with Gmail as a test case.
|High Priority||Medium Priority||Low Priority|
|Critical||Navigating to gmail.com results in a 500 Internal Server Error||Gmail crashes if a user logs onto more than one computer||Internet Explorer 9 users can’t access Gmail|
|Major||Email users can’t include attachments to their outgoing emails||Email users can’t include attachments larger than 500mb to their outgoing emails||Email users can’t include attachments larger than 1GB to their outgoing emails|
|Minor||Gmail.com displays an “ERROR” instead of “Gmail”||Gmail.com displays nothing instead of “Gmail”||Gmail.com displays “Gmail.com” instead of “Gmail”|
Q (and) A
When setting priority, why do we want Product Owners and Product Managers to have the final say?
Product Owners and Product Managers have a keen eye on the big picture. While something might seem like a big deal in your development environment, it might actually be largely irrelevant when the product is viewed as a whole. Conversely, an issue that you don’t see as high priority may be blocking 80% of your users from logging in. Consider them the final answer to the question of “who sets priority and severity?” Developers and testers certainly have input into the conversation, but product owners and managers have the last word.
What if I have an issue that’s even MORE severe than high priority? Can we create a Super High Priority?
If everything is top-priority, then nothing is. By being honest about what’s important, you’ll be able to focus on legitimately crucial things for your product and for your users, setting both you and your product up for success in the long run.
My department bears the brunt of product decisions, can’t I just set all my issues to “High” priority so they get done faster? My team will have my back and we can deal with whatever else we’re working on later
Yup, you can do this, and maybe you’ll even get your issue pushed to the top. Bravo, but…
The opportunity cost of making this decision is incredibly high.
The true purpose of assigning issues a specific class is to remove subjectivity from the maintenance process. Even if you do work in a key department – heck, even if you’re the product owner – it’s an essential misuse of the classification system to create a “me-first” channel. Not only that, but if you spend all your hours and budget tackling items that you’ve evaluated subjectively, you won’t have the time to focus what adds the most business value, like new features or key content; at the end of the day, your content is what’s bringing in fresh users.
If there’s one takeaway I want to leave you with it’s this: make the changes that matter. Priority and severity aren’t just a means to create a nice two-coordinate chart; they’re a way to keep you sane and productive amidst the chaos of maintaining a large-scale digital product. Make a habit out of assigning cases to every issue, especially in crisis situations. It’s easy to create a high priority, critical task named “fix the site”, but you’re much more likely to get faster, more tangible results by bundling out and triaging individual issues.