How JSM reports calculate SLAs?

[Eduardo Anflor - MindPro]

Hi there.

I am creating a new JSM report using a "Time to First Response" series and I would like to know what business rules the report uses to calculate the average time and breach

Examples:

• It seems that, when the issue is in a "Done" status category, the report does not count as a breach, even if the "Time to First Response" is breached for this issue. 
• I use JSM and another custom chart and, when comparing the values ​​between the two charts, it shows a large difference in values, and the custom chart I use uses the SLA calculation rules available in Jira’s documentation.

Does anyone have any clue or additional information about how these calculations are really made?

Thanks,

Eduardo

[Gizem Gökçe _OBSS_ · Accepted solution]

Hello @Eduardo Anflor - MindPro ,

Unfortunately, Jira's own SLA counters do not work backwards. Whenever an SLA is enabled, it starts calculating for issues that are within the SLA counter limits at that time. It does not calculate for issues whose SLA definition endpoint has been reached. If you want to see historical SLA breaches, you will need to extract data from the Issue History. You will find it much easier to use a third party application to do this.

Timepiece (formerly Time in Status) ,the oldest and leading "Time in Status" app in Atlassian Marketplace, which is developed by my team at OBSS, has a report type that will meet your need.  Our app is available for both Jira Cloud, and Data Center. 

In Status Duration report you can combine the time for multiple statuses to get metrics like Response Time (Time to first response), Resolution Time(Time to Resolution), Issue Age, Cycle Time, Lead Time  etc. 

As an alternative approach, Timepiece also has Duration Between Statuses report type which shows the duration between two specific statuses. This report type also allows the user to exclude the times for "pause" statuses. (Please see the screenshots below for both of the reports)

For all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example total in-progress time per customer or average resolution time per sprint, week, month, issuetype, request type, etc. The ability to group by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend. 

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

Visit Timepiece (formerly Time in Status) to explore and enjoy a 30-day free trial to experience the full range of features.

If you wish, you can also schedule a live demo. We will provide a comprehensive overview of the application and address any inquiries you may have.

Hope it helps,

Gizem

[Eduardo Anflor - MindPro]

Hi, @Gizem Gökçe _OBSS_ 

Thanks for your reply.

In fact, my case is that the issue were done after the Time to First response SLA has breached. I mean, I lost this SLA, but I met the Time to Resolution on time. So, as per my experience, the system should count one SLA met and one SLA breached for this issue. However, it does not count the breached SLA in the Jira report. For issues that are still open, it counts the breached Time to First Response normally.

[Gizem Gökçe _OBSS_]

Hi @Eduardo Anflor - MindPro ,

Actually this is what I was trying to tell you in my first answer.

Lets say you set your SLA's when your issue is in In Progress status. This means that the Time to First Response counter will not be effective for this issue because the first response has already been given. Unfortunately, Jira's native SLA counter does not calculate for issues whose SLA definition endpoint has been reached. But since your issue has the status In Progress and not yet resolved, the Time to Resolution is still on the table and your SLA counter works fine for Time to Resolution.

You do not see a Breached alert because the Time to First Response calculation has never been done by Jira. And this is exactly why I suggest you use a 3rd party application for this. Unfortunately, if you want to see historical SLA breaches, you will need to extract data from the Issue History.

This is a very tricky topic. I hope I can provide you with a clear explanation :)

[Eduardo Anflor - MindPro]

Hi, @Gizem Gökçe _OBSS_ all SLAs were set prior to creating the issues. I created a new project to test this. What I see is that some apps have a "breached ongoing" category for SLAs in issues that are still open. And a "Breached" for the issues already closed. Anyway, Jira Report is only counting the Time to first response as breached if the issue is open, even if the SLA was set previous to the issue creation.

For example: jira report shows 15 breached for time to first response, but I have 17 issues breached for this SLA. But there are 2 that are closed already, since they met the time to resolution on time:

These 2 issues below marked in green are being counted in the breached count for the time to first response:

I believe using something like "breached" and "breached ongoing" seems a good idea, but I do not know how to retrieve this from the API. Does anyone have any idea?

[Valeriia_Havrylenko_SaaSJet]

Hello @Eduardo Anflor - MindPro 👋

Jira Service Management (JSM) reports calculate SLAs based on predefined metrics and timelines set within the SLA configuration. Here are the key steps and considerations in how these reports are calculated:

1. SLA Configuration: SLAs in JSM are configured based on specific criteria such as issue type, priority, and customer request type. Each SLA has goals defining the target times for different statuses (e.g., "Time to First Response", "Time to Resolution").

2. Timers and Conditions: JSM uses timers to track the time an issue spends in different statuses. These timers start, pause, or stop based on the conditions defined in the SLA configuration (e.g., when the issue status changes from "Waiting for support" to "In Progress").

3. Time Calculation: The SLA timer includes or excludes non-working hours and holidays based on the calendar set up in the SLA configuration. This ensures that SLA calculations are aligned with the business hours and holiday schedules.

4. Reporting: JSM reports display SLA metrics such as the percentage of issues that met or breached the SLA goals. Reports can be customized to show detailed performance data over different periods and for various issue types.

5. Average Time to Resolution: Specific reports, like the "Average Time to Resolution", are calculated by aggregating the total resolution time for all issues and dividing it by the number of resolved issues [2].

Try Time Between Statuses as an alternative. This add-on measures connections in the workflow by tracking the time it takes for specific issues to transition between statuses. You can calculate the Time to First Response by setting start/stop and pause statuses in the configuration manager. Make sure to select the first/last transition to/from status to define the calculation conditions. 

Give it a try! The add-on offers a 30-day free trial version and is free for up to 10 users. It's developed by SaaSJet.

Hope it helps 😌

Please, accept my answer if you find it useful 

Thanks!

[Danut M _StonikByte_]

Hi @Eduardo Anflor - MindPro,

Hope this helps: https://confluence.atlassian.com/jirakb/how-to-understand-sla-reports-calculation-1318390764.html

Danut   

[Hannes Obweger - JXL for Jira]

Hi @Eduardo Anflor - MindPro

As you can see from the previous answers, this is an area where many Jira users rely on apps from the Atlassian Marketplace to fill some of the gaps in Jira's built-in SLA functionality.

If a Marketplace app is an option for you, you may want to check out the app that my team and I are working on, JXL for Jira.

JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields - including all JSM-specific fields - much like you’d do in e.g. Excel or Google Sheets. It also comes with a long list of so-called history columns that aren’t natively available, including time to first response, time in [status], time between [status] and [status], and many, many more.

All these history columns are calculated based on the issue's history at a given point in time, meaning that the data is available for all issues, regardless of whether an SLA has been defined or not.

This is how it looks in action:

As you can see above, you can easily sort and filter by your history columns, and also use them across JXL's advanced features, such as support for (configurable) issue hierarchies, issue grouping by any issue field(s), sum-ups, or conditional formatting.

Of course, you can also export your sheet to XLSX or CSV in just one click.

Any questions just let me know,

Best,

Hannes

[Mehmet A _Bloompeak_]

Hi @Eduardo Anflor - MindPro ,

The data you need is available in issue history and you can get it using Jira Rest API. It provides the exact status changes for each issue. It returns json, then you need to calculate it by coding which parses issue history rest api json for each issue.

Or you can try marketplace apps. We developed Status Time Reports app for this exact need. Here is the online demo link, you can see it in action and try without installing the app.

For a free solution, you can try the limited version Status Time Free.

If you have any questions, feel free to schedule a demo with us. Hope it helps.

[Eduardo Anflor - MindPro]

Hi, @Mehmet A _Bloompeak_ 

In fact, I need to know how to calculate the breaches, as in one of the above answers. Time in status is not the case, I need to know the criteria the API uses to classify time to first response as "met" or "breached". Because the OOB report does not seem to be accurate, since it only counts open issues in this SLA.

[Mehmet A _Bloompeak_]

Hi @Eduardo Anflor - MindPro ,

The information is available in Jira's issue rest api
YOUR-SUB-DOMAIN.atlassian.net/rest/api/3/issue/YOUR-ISSUE-KEY

In the response of Jira's issue rest api, the SLA fields have 2 sub attributes "completedCycles" and "ongoingCycle". Both of these attributes must be checked to detect breached issues.

Ongoing Cycle example:

Completed Cycle example:

As an alternative, you can try Reports - Charts and Graphs for Jira app developed by our team. It checks both ongoing and completed cycles and generates the chart.

If you are looking for a free solution, you can try the limited version Reports - Charts and Graphs for Jira Dashboard Free. Hope it helps.