Getting Actual SLA time of resolved issues

[#1]

Hello, Community! 

I would like to share a solution to a fairly common problem that you could apply in your practice.

The article consists of the following sections:

• Task
• What we have
• Decision

• What are the advantages of this solution

• Conclusion
• Some ideas

Task

Some time ago we ran into the following task:

"How to conduct analytics on the actual time spent on solving problems(retrospective analysis of closed issues)."

What we have

• Jira Service Desk - 4.1.0
• Jira Misc Workflow Extensions (JMWE) - 6.3.3

Decision

We used Jira Service Desk, where SLA is flexibly considered out-of-the-box.
This is a very convenient and useful feature, without which working with Clients would be less transparent and comfortable.

Some useful docs about SLA:

• Create service level agreements (SLAs) to manage goals

• How teams see SLAs

In simple words, the essence of the SLA in our case is to show "whether we have time to provide a service at the specified time or not?"

Therefore, we see for each issue:

1. either the time left for us to complete this task
2. either time exceeded (by how much we have already deviated from the "SLA Goal")

Also, when you hover the mouse cursor over on stopped SLA-indicator, the following appears:

1. SLA Goal (for example, "24h")
2. Actual time (for example, "2h")

As you can imagine, the actual time is exactly the indicator that we would like to analyze (build dashboards, upload to CSV/Excel and so on).

But, unfortunately, this indicator could only be obtained in the way described above (by mouse hover) and it was impossible to work with it.

To solve our problem, we used existing JMWE plugin.

Since our process involves one single transition to the final status, we have added 2 post-functions "Set field value (JMWE app)" on this transition, which calculate the actual time in 2 fields.

Field 1 (numeric field) - actual time of the solution in minutes.
The post-function consists of:

Field - "field1.name"
Value type - Groovy Expression

Value -

try {
return issue.get ("SLA field name"). completeSLAData.last (). elapsedTime / 60000
} catch (Exception e) {
return null
}

Where - SLA field name is the name of the SLA metric you need.
Result(for example) - 74.371

Field 2 (text field) - the actual time of the solution in a pleasant-to-read format.
The post-function consists of:

Field - "field2.name"
Value type - Groovy Expression
Value -

import com.atlassian.core.util.DateUtils
try {
return DateUtils.getDurationPretty (((issue.get ("SLA field name"). completeSLAData.last (). elapsedTime) / 1000) .toLong (), ComponentAccessor.jiraAuthenticationContext.i18nBean.resourceBundle)
} catch (Exception e) {
return null
}

Where - SLA field name is the name of the SLA metric you need.
Result - 1 hour, 14 minutes

It is also possible to set the following Options or Conditional execution:

What are the advantages of this solution

• We try as much as possible to use the out-of-the-box capabilities of Jira Service Desk - in this case, project-administrators are responsible for all SLA settings, they can flexibly define “working hours” and “weekend calendars”, change the conditions for starting / pause / stopping the calculation of SLA-indicators, etc. (for us it is extremely important).
• This solution can be easily reused in other processes.

Conclusion

We have achieved a fairly simple and flexible solution for the task that we faced.

If you have any ideas how we could improve our solution, please let us know in the comments, we are ready for changes for the better.

If you have any questions - also do not hesitate to ask them in the comments.

I would like to thank the JMWE support service - you can always turn to them for help and get a high-quality recommendation and solution to the problem!

Some ideas

In our case, we counted the actual time at the time of resolving (closing) the problem, but if you need to understand the actual time spent at any moment, you can look at the JMCF plugin that will allow you to create a scripted field.

Good luck!

[baz89103]

Dear @Alexander Bondarev 

what do you mean by SLA field name?  does this calculate time between start of issues and when it is resolved?

[Marc Isikoff]

Great, but we are barred from using extensions or any Marketplace plugin.

Thus it makes us feel like Atlassian gets an "F" in terms to getting us pretty common sense needed features that they offload to Marketplace developers.