Priority and Severity of tasks and bugs

Priority and Severity of tasks and bugs identified during the testing life cycle are two essential notions of risk assessment that are often considered to have the same meaning. However, differentiation of these attributes is significant in the development process because allocating them to issues helps effectively determine the order in which release tasks are to be performed. This article will cover defining Priority and Severity, setting Priority and Severity for defects, creating a Priority/Severity matrix and giving some useful tips for implementing the matrix into your project.

Definition of Severity and Priority

Along with other properties such as release or fix version, sprint version, description of system behaviour, etc. of issues in a task tracking system, Priority and Severity are still the most practiced through the release management processes. To clearly understand them, definitions of terms will be given below.

Priority and its levels

Priority is the order in which a bug/task should be resolved. In other words, Priority shows the importance or urgency of fixing defects and implementing issues. This attribute depends on the Severity of the product systems and the business necessities.
Priority levels can be divided as follows:

• Low - a defect/task can be fixed last or can not be fixed at all;
• Medium - a defect/task should be resolved in the subsequent builds with consideration to the tasks queue;
• High - a defect/task must be resolved as a first priority since it blocks overall or affects critical functionality of the product, but it has a temporary solution or workaround;
• Blocker - a defect/task must be resolved immediately since it blocks overall or affects critical functionality of the product and it does not have a temporary solution or workaround.

Severity and its levels

Severity is the level of impact of a task/bug on a product. The Severity level indicates to what extent issues and glitches affect the functions, performance or public perception of the product.
Severity can be of following levels:

• Low - a defect/task does not have an impact on the functionality or image of the product;
• Medium - a defect/task has a small impact on the functionality or image of the product;
• High - a defect/task has a significant impact on the functionality or image of the product, but it has a workaround or temporary solution. In addition, this affects the number of end users allowed (a certain percentage);
• Blocker - a defect/task blocks overall or affects critical functionality or image of the product badly. It does not have a temporary solution or workaround. Moreover, this affects an unacceptable number of end users.

Priority and Severity setting

Typically, having detected certain bugs through the process of testing, a QA team assigns both Priority and Severity attributes to each defect to indicate the extent to which they affect the project's systems. Since Severity represents an eventual impact, QA engineers identify systems and their functionality affected by the bug, assess the presence of a workaround and evaluate the number of audiences under this effect. It helps determine the Severity level correctly. However, this level can be changed in the assessment procedure by stakeholders because they have an understanding of the system as a whole from a business point of view.
Although the QA team has already set the initial level of Priority during the test cycle, a Product Owner or a Project Manager defines the final order in which the bugs and tasks will be performed in a sprint by a development team.
It could seem that Priority completely depends on the level of Severity, however, Severity is the coefficient which may increase the level of Priority and decrease it as well. The following will show how easy it is to set the Severity for bugs.
Nevertheless, before setting the level it is necessary to recognize which components of the project are crucial from different points of view such as business, legislation, privacy, functionality, data, etc. This list of key systems should be allocated together with stakeholders and it should be fixed in the documentation of the project, for example, in a confluence page where every team member can see information about each component and its level of criticality.
As an example, the following critical systems can be distinguished:

• Everything about money (e.g. order confirmation for an online marketplace);
• Everything about data (e.g. payment data);
• Everything about legislation or legal area (e.g. user agreement);
• Any kind of core functionality (e.g. market data collection for brokers);
• Functional safety (e.g. airbags for cars);
• Cyber security (e.g.personal data).

Easy checklist to set Severity for a bug

There are several questions which should be asked in order to set the level properly:

• Does it affect safety or privacy?
• Is an impacted system crucial to a product?
• Is there a workaround or temporary solution for an issue? Can any user use this solution?
• How many users are affected?
• Is influence critical to a product's image? Could this negatively affect the product or business?
• Does it have an impact on business partners?
• Does a problem increase the company's legal risks?

According to the list of declared critical systems and the list of questions, QA specialists can select the appropriate level of Severity for each defect and set it in a task-tracking system along with its Priority.

Priority/Severity matrix

Since the level of Severity influences Priority, the final level of urgency must be adjusted. Before the correction, stakeholders and a tech team should arrange the interconnection of levels of both attributes. Regardless of common levels of Priority and Severity that were mentioned previously, they might have other names than “high”, “low”, etc. and can be named as “crucial” or “trivial” because it directly depends on terminology in your project. However, the most convenient approach is if attributes will have the same name and degrees of criticality because it facilitates comprehension and assignment of the estimate. Moreover, to simplify the application, the definitive level of Priority of tasks or defects creates the matrix of mapping Priority and Severity. An instance of such a matrix is given below.

How to create your own Priority/Severity matrix

The following steps may help facilitate the creation of the matrix for your own project:

• Take a default matrix in the first step;
• Adapt it to your project Priority levels and names;
• Decompose your project to systems;
• Define the list of critical systems of your project.

Firstly, according to this approach, taking and adapting an already finished matrix allows you to focus on filling the list of urgency which is associated with your project instead of generating ideas about the representation form of the matrix.
Secondly, in cooperation with development and QA teams, you should determine all systems that are included in the project. Last but not least, note the most crucial components which require scrutiny in the processes of development and testing.
After implementing these steps, you get the matrix which reflects the dependence of Priority and Severity and the catalogue of the most important parts of your product. Both received artifacts allow your team to set proper levels of urgency for tasks and bugs correctly and will act as an argument in case of disagreements with stakeholders when choosing one or another level.

How to implement a new process to your project

Here is the way to include a new process for working with the matrix of Priority and Severity in your project:

• Present the concept to your project manager. Your management should realize how a new process might improve the estimation of tasks and defects during a release procedure and facilitate interconnection with tech teams, especially, in cases of disputes about the priority of implementation issues or fixing bugs.
• Show an adapted matrix and the list of critical systems for your project. It allows you to arrange with the management a choice of approach to evaluation and accept the scroll of components which will be under control.
• Pursue the goal of improving bug/tasks management. Point specifically to the fact that this process will be in your area of responsibility. It is important to show your management that you will lead and keep under control the enhancement of an evaluation process in your team.
• Discuss. Find an optimal formula for your project together. Frequently, any changes in the process face resistance from management and other team members. It requires time and negotiations to come to a common point of view on the process and accomplish success in building a new assessment procedure.
• Create a wiki/confluence page to consolidate a final formula. Fixing agreements is a significant point that allows your team to avoid violations of the evaluation process in the future.
• Create a Severity field in your task tracker system for your project. For example, Jira does not have a Severity field in basic settings and you should ask a relevant department to set this attribute and its values in the task tracker.

Priority and Severity are attributes on which the assessment of the impact of tasks and defects on the product is based. As was already mentioned, Priority is the position of an issue in the queue, while Severity affects Priority and may decrease or increase precedence and correct it. Furthermore, the Priority/Severity matrix is an instrument to manage bugs and tasks arrangement. This is especially useful for a project with plenty of bugs and tasks, and in this sense, understanding and the ability to arrange and incorporate the process suitable for your particular project is essential.