Priority and Severity are the foundational methods to categorize work items in software development. With the agreement and buy-in across the team on the accepted definitions, it is much easier to order and schedule work.

Below are the industry standards for Priority and Severity. Do not stray from these definitions. You will only end up dooming your team to failure.

Priority
An organizational ordering of the work item. It is not based on how hard the problem is or who it affects. It defines importance to the team. It typically affects when the work will be scheduled.
1 – High – Most important/valuable to the organization. We will fix this bug first.
2 – Medium – Moderately important. We’ll fix this bug eventually.
3 – Low – Least important. We’ll fix this bug when we get around to it.

There is no need for more than 3 levels of prioritization.

Severity
A technical categorization of the bug. How much of an effect does the work item have? Is it the game changing new feature that we think will make our profits soar? Is it the terrible bug that every one of our users sees every time they login? Maybe it’s just a typo on the About Us page. Severity defines the what. There are 4 levels of severity:
• Critical – This is a serious. Wake up the CIO. Some part of the system is down and it is affecting all customers. There is no known workaround. If necessary, all hands on-deck to get this done.
• Major – Some part of the system is not working properly, affecting all customers. There is an effective workaround.
• Minor – Some part of the system is not working properly, affecting some customers.
• Low – Pesky problem for some customer, but they can live with it until we fix it.

Blockers
A blocker is neither a Priority nor a Severity. Do not get caught in that trap. A blocker indicates that something is blocking something else from occurring. A bug can block other bugs from being tested. Knowing that something is a blocker can affect the bug’s priority.