Deiser Blog | Atlassian | ITSM | DevOps | Agile at Scale | Cloud

Create a prioritization matrix in Jira Service Management Cloud

Written by Antoni Pérez Gómez | Sep 28, 2021 2:45:00 PM

Having prioritization standards at a service desk or helpdesk it's decisive when it comes to boosting productivity. This process affects equally the customer and the team handling the ticket; that's why we'll explain how to create a prioritization matrix or priority matrix that allows taking quick and accurate decisions when receiving a ticket in Jira Service Management environment.

Jira Service Management (JSM) brings by default a system field called "Priority" that serves us perfectly to model this concept. It is usual to find the mistake of including this field in the input form of the user portal. The priority should not be left to the user's discretion or the agents; the priority should be established based on the initial establishment of objective criteria agreed by the team.

Here's where the prioritization matrix or priority matrix comes into play; in JSM, we don't have a way to implement the matrix for our cash flow incidents, for example. Let's go through this proposal to build a prioritization matrix for JSM. But first:

What is a prioritization matrix?

A prioritization matrix is a tool that enables an objective, consensual, and unambiguous way to determine and rank which main tasks the team shall invest their efforts in, in our case, applied to the Information Technology Services Management (ITSM) area, to deliver an effective service to customers.

Having a priority matrix defined, agents will not spend time nor effort determining which task to work with next; instead, they will tackle the next highest priority task in the work queue.

The most common approach for this prioritization matrix application is through a two-dimensional system illustrating the impact on one axis and the severity on another. Personally (and this criteria is debatable), the concept of urgency might be subjective; that's why I prefer to use the term severity.
Let's define these two concepts before we continue to establish our priority matrix:

  •    When talking about Impact, we'll refer to what determines how many people or how much activity is affected within the team.

  •    The Severity determines the level of service degradation that the incident we are facing will cause.

Pros and cons of establishing a prioritization matrix in Jira Service Management

Pros:

  •    Our tickets will be automatically prioritized.

  •    We'll prevent arbitrariness and subjectivity from getting in the way when determining tickets priority.

  •    Service desk agents shouldn't spend time nor effort figuring out what to do next when they complete a task.

  •    We'll ensure critical tasks are completed in the shortest time possible.

  •    We'll use Jira as it comes out of the box, without the need to purchase any app or building complex custom developments.

Cons:

  •    If you're working with the Atlassian Cloud Standard plan, it will be necessary to replicate the automation in all of the projects instead of using a global one; that plan has a monthly limit of global executions.

How to create a prioritization matrix and how to bring it to Jira Service Management Cloud?

Now let's define the values of Impact and Severity; once determined, we'll have in this simple prioritization matrix we're building, and finally, it allows us to calculate the priority. Commonly these values are represented with numbers or with adjectives such as High, Medium, and Low.

It's advisable to use less corporate/technical language to avoid disruptions in the prioritization. Imagine if a person in charge who provides the information is a user unfamiliar with the terminology established. This is why our suggestion is the following:

Impact Severity
  • It only affects me.
  • It affects one or more teams.
  • It affects the entire company.
  • I can work normally.
  • I can work with difficulty.
  • I cannot work.


This way, users will understand the request, and we'll be able to define our matrix by translating their responses to quantitative values. Let's define our priority matrix:

Severity \ Impact It only affects me It affects one or more teams It affects the entire company
I can work normally Low Low Medium
I can work with difficulty Low Medium High
I cannot work Medium High Critical

From now on, this model will help us to automatically prioritize our tickets! Consequently, We'll have ordered agent queues, it will be easier to estimate SLAs, create alerts, among other things.

How do we take this matrix into our Jira Service Management? To implement the prioritization matrix we've defined, we'll use tools JSM Cloud plans already have regarding custom fields and Automation.

First, we need to create two custom fields to model the Severity and the Impact. These fields must be a Select type; there, we'll introduce the values as lists, those we've defined previously. Let's see how it will look in JSM:

In this screen, we'll define the values of the field Severity:

In this screen, we'll define the values of the field Impact:

Next, we'll add the fields for the ticket creation screens. Let's include them in the Request Types, so they correspond to our system incidents. In the Request Type, we change the copy to make the language more closer to the user, e.g.:

We also must make sure the Priority field is not in the creation or editing screens. It should only be displayed on the display screen since it will be a calculated value. In the situation of a manual reprioritization, we would be able to create a transition that allows us to control through a condition that only specific roles (e.g., the service desk coordinator) can manually reprioritize an incident and justify it.

In the Jira attribute settings, we will configure the values of our priority matrix:

Now it's only left to implement the Priority calculation based on the Severity and Impact defined earlier. For this last step, we'll use Automation, with the following components:

  •    Trigger: Issue Created. This rule will be executed when the incident is registered in the system.
  •    Condition: If / Else Block. We'll create bifurcations for each combination of Severity and Impact.
  •    Action: Edit Issue. We'll edit the Priority field depending on the casuistry of the branch we're in.

Finally, let's create the rule:

Learn how to automate tasks that react to project actions in Jira >>

This is one of the multiple approaches we can take. It's also possible to do it with JQL conditions, although it's a bit more complex. That's precisely one of the greatest attributes of Jira in general, there are different ways to achieve your goals, and we encourage you to discover new ways to calculate the priority matrix. If you have any comments, we would love to read them below.