Understanding Jira's Time to Resolution and Time to First response

[paul_creedy]

Could someone give me the lowdown or article on getting ones head around the Time to resolution raw data that is in Jira?

We have these fields:

Time_to_resolution_Actual_MS: (which is in milliseconds and has some negative numbers such as -105,987,136.00)

Time_to_resolution: which shows text as 41h 43m or -29h 26m (again negative numbers)

Time_to_resolution_Actual: as 77h 26m which actually makes sense, but you can't sum that column because it's a text field

Time_to_resolution_Actual_Timestamp: such as 77:26, which again you can't sum or average.

How are some of these values negative? Is the ticket resolved before it's even started or existed?

The only field that makes sense is Time_to_resolution_Actual but because it's a text field you can't SUM or Average it against an Axis

Surely there is a time to resolution value somewhere that I can use to Sum or Average how long tickets took to resolve within a specific grouping.

Time to resolution being the time between the ticket first being opened to when it was last marked as resolved.

Same issue for Time_to_first_response

NB: I'm bringing this raw data into PowerBI so I'm not interested in third party add-ons.

Thank you

[paul_creedy]

Thank you for confirming Sam

It does seem like there is no native 'true' time to resolution or time to first reply, and those values are actually SLA related.  I was confusing the built-in values with my own expectations of what they meant.

Both time to resolution and time to first reply are important metrics for a service desk to measure response times, particularly when grouped against different types of issues (or agents).  I'm very surprised that JIRA doesn't have those baked in.  

Scanning other community posts, I can see that I'm not the only one with the same confusion.  Wonder how many users are using that metric incorrectly and made the same assumption that I did.

For future readers of this post:

The first reply and time of resolution in Jira is in reference to the SLA's.  This is why you get negative numbers. They do not mean the traditional 'first reply time', 'full resolution time' that one would expect if following ITSM metrics.

If you want stats with the traditional meaning you have to calculate it yourself.

You get more flexibility by using a PowerBI Addon exporter (there's a few of them in the market place), and then using the free PowerBI Desktop app to consume that feed for your statistics.

Here are the custom column fields I've ended up with (so far):

c_FirstReplyHours = DATEDIFF(Issues[Created].[Date],Issues[Status_Changed_Date].[Date],HOUR)

c_FirstReplyDays = DATEDIFF(Issues[Created].[Date],Issues[Status_Changed_Date].[Date],DAY)

c_WaitToResolutionDays = DATEDIFF(Issues[Created].[Date],Issues[Resolved].[Date],DAY)

c_WaitToResolutionHours = DATEDIFF(Issues[Created].[Date],Issues[Resolved].[Date],HOUR)

This allows you to produce a graph around month and priority to show how the agents are 1st lining the tickets based on priority.  For example, you would expect agents to react quicker responding to higher priority tickets than to lower priority tickets.  Median is used in preference to Average so as to exclude those random long running tickets that you always get in a busy system.

Sample:

Hope this helps future readers.

[Samuel Gatica _ServiceRocket_]

Hi @paul_creedy 

Please refer to the following articles:

How Resolution Time is Calculated 

"First Response Time" report and how to use it 

Best Regards

Sam

[paul_creedy]

Hi Sam 

Thanks for this links

What I don't understand is that if the resolution time is resolved date - created date how on earth am I getting negative numbers returned.  The negative numbers seem to be in relation to whether the SLA breached flag is set or not.  Negative numbers shouldn't be possible in a resolution calculation.

The only non-negative resolution time is a text field such as 21h 2m, so that is useless for calculations such as getting the average resolution time due to those negative values.

Likewise, the first response time has the same problem.  How is it possible to have negative first response times, and again the only field that seems to calculate it correct is a text field.

Attached is a screenshot with negative resolution times highlighted.

Paul

[paul_creedy]

Looking at these further and comparing to Jira I think these definitions are not quite what I was expecting.

These appear to tie in with SLA definitions.  The time to resolution in the table above being how much longer before the SLA is broken, and the negative numbers reflect how much past the SLA it continued before it was resolved.

If that is the case then this isn't the same understanding of 'resolution time' I was looking for.

What I'm looking for is the actual time it took to resolve an issue start to finish.  From when it was first created to when it was last marked as resolved, how would I get that value?  A more precise definition would be "How long did the customer wait until their issue was resolved?"

Likewise for Time to First reply, this should be "How long did the customer wait until an agent responded to their request for help"?

Any idea where or how I would calculate those fields?

[Samuel Gatica _ServiceRocket_]

Hi @paul_creedy 

The Time to Resolution and Time to First Response are fields used by SLA and JSM functionality only.

Unfortunately, Jira does not have a native field that calculates the Time to Resolution.

If you use boards, you can see how long a certain issue is in that column. You need to go to your board settings > card layout > days in the column.

Alternatively, you can add a new custom field 'Time to resolution' that you fill in automatically when you resolve an issue. You can compute the days from creation till resolved with smart values {{now.diff(issue.created).days}}.

Hope this helps

Best regards

Sam

[Marc Isikoff]

By far, the easiest way to track time for SLAs, is to create custom date/time fields for your project, and automate when an SLA action occurs (breach, resolved, commented) you give {{now}} to that field, essentially captures as a date/time field when they occured.

The reporting angle is a little difficult because custom field resolved time less created time is just wall time. You will need to factor your business hours into that to get true time worked.

But for breaches this is gold; you can accurately give the date and time a breach happened, not just everbreached().