JIRA Service Desk Tip: Why was our SLA breached?

JIRA Service Desk allows you to configure custom Service Level Agreements (SLA) based on custom issue types, priorities or any other field you want to use. Of course, the goal of your team is to meet the SLA’s, but what happens when they don’t? And more importantly, how can you find out why SLA’s have been breached? In this blogpost I will show you how to easily document SLA breaches in JIRA Service Desk.

SLA Setup

An SLA is made up of two settings:

  1. A time metric, which lets you define how time will be measured for this SLA;
  2. A goal for selected issues, which lets you define a target for the time metric (different sets of issues may have different goals).

SLA+metric+setupThe actual SLA results are shown in reports and in the JIRA issue itself.

sla-visibility-600x283

Custom fields, Screens and Workflows

To document SLA breaches, we will first need to create a new custom field called SLA breached explanation

Screen Shot 2016-02-04 at 15.38.34

The next step will be to create a new screen called SLA breached screen which has the SLA breached explanation custom field assigned to it. This screen will then be used in a workflow transition, but only when the SLA has been breached (more on this later).

Screen Shot 2016-02-04 at 15.39.29Here’s an example of what our workflow could look like. Note that we added a workflow transition called Resolve breached issue between the Waiting for Support and Resolved statesNow we have two transitions going from Waiting For Support to Resolved. The first transition (Resolve this issue) simply goes to the Resolved state. For the second transition (Resolved breached issue) however, you will need to assign the SLA breached screen to the transition so users can provide an explanation for the breached SLA.

Screen Shot 2016-02-04 at 16.18.07

screen transition

Workflow Conditions

Out of the box, JIRA does not support adding workflow conditions based on a JQL match. In order to achieve this we’ve installed ScriptRunner for JIRA by Adaptavist.

Let’s now configure our workflow with the conditions we need. Select the workflow transition Resolve breached issue and select Conditions. Now select the Script Condition.

conditionsHere, we want to make sure the Resolve breached issue transition is only shown when the SLA is breached. For this we will use the following JQL Query:

“Time to resolution” = breached()

resolution breached conditionFor the transition Resolve issue we want to configure a condition as well to make sure it only shows up if the SLA has NOT been breached. For this we will use the following JQL Query:

“Time to resolution” != breached()

resolution not breached condition

Results

When we now look at an issue, in this case an issue with an SLA breach, we will see the transition button Resolve breached issue.

issue view sla breachedWhen clicking Resolve breached issue we will see our SLA breached screen and will be able to provide an explanation for the breach through the SLA breached explanation custom field.

sla breached popup* You could of course configure a validator and make this field mandatory.

Looking at another issue, in this case an issue where the SLA has been met, we will now see the transition button Resolve this issue. Clicking the button will simply Resolve the issue.

Screen Shot 2016-02-04 at 18.07.07

 

 

This should enable you to report on SLA breaches with much more detail and (I hope) perhaps even lead to less SLA breaches!

Hope you enjoyed the post. Feel free to leave your questions and comments below.

  • Facebook
  • LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>