With Sifter, we went with a simple priority system and some approximate corresponding definitions. Unfortunately, everyone has different interpretations of what these words mean. So while it’s best for each team to customize and ultimately agree upon what these words mean, we thought a baseline could help you establish some ground rules. Here’s what we use:
- Critical – An entire swatch of functionality is inaccessible due to this problem. A great example of this would be if the authentication system for a web app was broken and nobody could login. That’s definitely critical.
- High – A significant piece of functionality is completely broken, but it’s isolated to a single part of the system. An example here would be if the “Forgot Password” functionality was broken.
- Normal – The baseline. Something is clearly broken, but it’s not stopping anyone from doing their job. A solid example here would be if a link was broken, but there were still plenty of other ways to get to that functionality. You definitely want to fix it, but it’s not high or critical.
- Low – We should definitely do something about this, but only after everything else is finished. This could be a typo, spacing problem, or just a minor browser issue.
- Trivial – The world isn’t going to end if we don’t get to this. This will usually be enhancements or other items that are more of a personal preference nature. They’re good to jot down and keep track of, but they don’t have to be completed to launch.
Ultimately, all that matters is that the entire team is on the same page. If a someone is filing everything as critical when it isn’t, then it’s important to talk to them. Abusing the priority field is counter-productive, and, in some cases, it’s best to not specify priority up front at all. You can even have official prioritization meetings where you sit down with clients or stakeholders to agree upon the priority for each issue. Regardless of how you approach it, just remember: If everything is critical, then nothing is.