Manuscript uses a “Priority” system but other issue trackers often opt for “Severity,” or even a hybrid of both. What’s the difference between “Priority” and “Severity?”
Every case in the system is given a priority from 1 to 7, where 1 is the highest priority. The default for new cases is 3. You can rename each priority’s text label to suit your preferences. To change the labels:
- Log on as an administrator
- Click on the Admin menu and choose Priority
The best way to use priorities is to have a single, global priority scheme across all your projects, bugs, and features so that every team member can always work down their list of cases in order of priority.
Here is a typical scheme you might use:
- Life or death emergency… the roof is actually on fire. Drop everything and fix.
- A customer is waiting for this to be completed.
- Very important
- Not so important – fix if time
- Probably won’t fix but worth remembering
- Do not fix
The Evidence-Based Scheduling reports assume that you are going to implement features in order of priority, and they can show you different schedules based on how many priorities you choose to do. Assuming you have estimates, it will let you see how much it would affect your schedule to do those “fix if time” features.
Priority vs. Severity
Priority represents the importance of fixing a bug, and reflects a business decision as to how soon that bug should be fixed: all priority 1 bugs should be fixed before priority 2 bugs, and so on.
Severity represents “how bad a bug is”. For example, a bug that causes the program to crash would be considered high severity, while a small spelling error might be low severity.
But wait a minute … if that spelling error is in a frequently-used part of the program, it might give an overall bad impression that hurts the product’s sales. And if the crashing bug happens extremely rarely and only under very unusual circumstances, you may decide that the spelling error is actually more important. So you could imagine having a high severity bug with a low priority, or vice versa.
Manuscript is designed so that the only thing you need to enter and store is the priority. You need to decide which bugs are going to get done first, and you need to be able to search for high priority bugs or sort bugs by priority. But if a bug is a low priority, the additional piece of information that it is “high severity” is merely confusing, since you’re still not going to fix it until all the higher priority bugs are done.
Manuscript has a general principle of not requiring users to input data unless it’s going to be used later. If we required bug submitters to decide both the severity and the priority of a bug, that would increase the amount of thought and work it takes to enter and manage that bug. Each time you enter a bug, you would have to make two hard decisions, while only one of those choices really matters in the long run. Most of the time, the priority and severity are the same; when they’re not, the severity is not worth keeping track of.
Our years of experience with bug tracking software have taught us that the most important factor in successful bug tracking is getting every bug captured in the system. We’ve found that in the real world, anything which increases the mental friction of inputting a bug will dramatically reduce the number of bugs entered. In this case, we strongly believe that requiring the person who inputs a bug to think about both the priority and the severity is more of a hindrance than a benefit to successful bug tracking. The fewer required fields you have, the easier it is to enter bugs and the more useful Manuscript will be.