How Severe Is Severe

Last month I talked about how a set of priorities is nice, but whenever the size of a set of priorities is less than the number of items being prioritized you have a problem and an ordered list of items is needed. Priority is just a way to order the operations. So how do you come up with the ordered list? That's where severity comes in.

Severity is a measure of the impact of a bug or work item. It lets you know how important an item is, and should be measured in terms of user impact. What does this item, or the user level item it rolls up into, make possible. For simplicity let's talk about severity in terms of bugs or defects. Using the `infra` bug template as a starting point, severity is how big the impact is. What can't the user do because of the bug?

• Sev 1: Causes a system crash or data loss.
• Sev 2: Causes major functionality loss or other severe problems; product crashes in obscure cases.
• Sev 3: Causes minor functionality problems, may affect "fit and finish".
• Sev 4: Contains typos, unclear wording or error messages in low visibility fields.

And that's really all there is to severity. It gets interesting because severity alone isn't enough to build an ordered list. If it were, then why would you need more fields? You need it because there's more to the prioritized list than just severity. The other two big things that go into prioritization are cost and number of users.

It's the combination of severity, cost, and impacted user count that lets you order the list. Severity and number of impacted users define the business impact of fixing and issue. And given a fixed amount of "points" to spend on the cost, you can maximize your *business impact*. That's how you decide if you should fix 2 or 3 big ticket items that a small percentage of your users will run into or fix all of those little niggling details that annoy every user multiple times a day. It is almost certainly more important to fix the bug in the method that occasionally overlaps street names on a map you have 5 or more roads merging than to get the "OK" and "CANCEL" buttons to line up and be centered, but what if you could fix 100 layout issues that everyone sees every day, eliminate a click or two from a workflow, and fix all of the spelling errors for the same cost? Is that more important than making sure the road labels on the Swindon Magic Roundabout are correct? Probably.

And the same logic applies to new features as well. Add one big feature for a handful of power users, or something 98% of your users want? It depends, and to make the decision you need the impact of a feature, how many users want the feature, and the cost.

And that's why severity matters.