Every software developer in this world has one mission:
via GIPHY: A developer celebrating building a new feature!
so what we do is:
Building new features. And some features come with little extras we usually call them bugs!
Not all features are important equally to the business. We need to order them and give each one priority value.
Not all bugs are severe equally to the business. We need to order them and give each one a priority value as well.
Each bug has an extra parameter called severity.
In this post, I will explain the difference between Priority and Severity.
What is Priority?
Priority is a parameter value that is assigned to each backlog item, Task or bug. Based on that value, we decide the order in which the backlog items will be built or the bug will be fixed.
The priority value is usually a number (1,2,3,4,5). Its value for a specific backlog item can be changed based on the current development phase.
According to Scrum guides, It’s the product owner‘s responsibility to set the priorities of the backlog items. Priority is subjective and anyone in the organization wanting to change the priority should talk to the product owner.
What is Severity?
Severity is a parameter value that determines how bad the bug defect is and how it affects the business.
The severity value is usually one of the following:
- Critical: a complete shutdown or block for the system or a feature
- Major: a partial collapse on the system
- Medium: the system is still working but some behavior
- Minor: no major defect on the system
- Cosmetic: no effect at all on the functionality
The description of each severity level above is just to clarify the idea.
Each organization / Technical team may set a more concise description of each level.
The Severity value of a specific bug is never changed regardless of the current development phase.
Severity is determined by the QA (Quality Assurance) team members. Severity is objective and it’s related to a quality standard followed by the team and the organization.
Priority and Severity Example
let’s have a practical example to clarify that a high severity level is not paired with a high priority all the time.
Let’s suppose our QA team identified a new bug that causes a data loss in the system. It goes without saying that such a bug has a critical severity level.
So what is the priority level for this bug?
The quick answer is: It’s the product owner’s job to find out when to resolve this bug.
let’s suppose that the goal of the current phase of the project is to prepare the first demo for the customer. The customer is expecting to see the features A, B, and C to give the initial feedback.
So we are still in an early phase before going to production. In that case, the bug has a low priority even if its severity is high.
The hight priority goes to features A, B, and C.
The Key Differences between Priority and Severity
| Priority | Severity |
|---|---|
| It is about when to work on the issue | It’s about how bad the issue is |
| Dynamic and can be changed | Fixed and doesn’t change |
| Any backlog item, Task or a Bug has a priority | Assigned for bugs only |
| A subjective value | An objective value |
| Estimated by the product Owner (in Scrum) | Set by QA |
Finally, I would like to mention:
- Understanding the importance of the priority and severity
- Distinguishing between them
- Using them the right way in the software development lifecycle
will help to maximize the value of the effort spent by the team.
The business needs to spend time on solving the most urgent problems (highest priority) and get the job done.
Speaking of Done! What do you mean exactly when say: It’s Done