Metrics and Reports by SolveroX

Please see our video on Youtube: https://www.youtube.com/watch?v=J5zbuBdhIyU

• How is our team doing overall since the beginning:
  project = Helpdesk
• How is our team doing overall regarding only the closed work items in our own Jira project:
  project = Helpdesk AND status = Closed
• How am I (or is Kevin) doing this year:
  project = Helpdesk AND assignee = 557058:a311c218-80fc-4184-8cf2-d5ce9b847506 AND created >= -365d
• How was our service to Acme Corp in months:
  project = Helpdesk AND Organizations = "ACME Corp" AND created >= -365d
• How is our service delivery for our customers with "Elite Support" Package:
  project = Helpdesk AND "Support Type[Short text]" ~ "Elite SLA"

Note: If you write your JQL in Jira - Advanced JQL search bar, it helps you auto-complete your JQL.

Dont know how to write JQL: Consult with a well-known AI assistant and ask it to write it for you. Just make sure that you have project=your_project_name in your JQL to keep the report only for your project.

1. Enter a JQL for a single Jira work item that you want to make the calculations detailly. Example: key = SUPPORT-27876
2. Fill in all the statuses one by one for the "Time on each status" report. Example:

   c=waiting for customer
s=waiting for support
i=in progress
e=escalated
p=pending
collective=waiting for customer+waiting for support+in progress+escalated+pending

3. Do your calculations manually or share:
   • screenshot of the entire work item history
   • screenshot of your SLA definitions
   • screenshot of the entire report we generated to your well-known AI, and ask it to calculate the results for you.

This will make you fully confident on how our calculations work flawlessly.

PS: Please familiarize yourself with two different methods of calculations and what they show. If you see any discrepancy, please share the relevant info with us and let's see together.

1. Click on the table row to see the details to see which work items are in the tme bucket.
2. Click on any graph bar or line point to see which work items are used to build that graph value.

For all calculations, only the metrics that can be fetched are used.

For example, if a work item has first response time but it is not yet resolved, it only contributes to first response and first time SLA(if defined) metrics, but not to the resolution and resolution SLA metrics (and time to done as expected).

Or if the application is able to fetch only partial data for a jira work item, such as only "ticket priority", because of a transient error (also shown as xx issues in error on the UI), this ticket contributes only to the "tickets by priority" calculations.

This application provides 2 reporting methods:

1. Ticket Creation Date: focuses on service quality from the customer's perspective. It groups results by when work items were created and answers the question:

   "For the work that arrived during this period, how well did we perform?"

   This view is useful for measuring customer experience and the outcomes delivered for a specific intake period.

   When Jira SLA data is available, calculations use Jira SLA timers and calendars. For the time-based metrics, if SLA data is not available, the app can fall back to wall-clock calculations. This allows you to still analyze service speed even if SLAs are not configured in your Jira instance.

2. Event Based: focuses on operational throughput from the team's perspective. It groups results by the relevant event date for each metric, such as an SLA stop date, resolutiondate, Satisfaction Date, or another metric-specific event date.

   "During this period, what work was completed, and how did the team perform?"

   For metrics that have a close Jira / JSM equivalent, this method is designed to follow Atlassian-style bucketing as closely as possible. For app-specific metrics, the logic remains specific to this application. Because of that, some reports can be compared closely with Atlassian's native reports or gadgets, while others should be understood as app-specific extensions.

A practical example:

If you resolve a 1-year-old ticket today, your internal teams may want to measure that result as part of today's operational output. That is the Event Based view.

At the same time, customers may want to know how well you handled the tickets that were created 1 year ago. That is the Ticket Creation Date view.

While "Ticket Creation Date" shows customer-cohort / service-quality view, "Event Based" shows event-date / operational-throughput view.

When you create your Jira instance, by default, usually these three statuses are considered as "Done" in the workflow:

• Cancelled
• Resolved
• Closed

When you create your Jira instance, by default, usually only these 2 SLAs are defined:

1. Time to First Response
2. Time to Resolution

• If you do not define Time to Done SLA, your Time to Done metric will calculate the time between the work item creation and the latest status change to any of the "done" statuses using wall-clock.
• If you do define Time to Done SLA, your Time to Done metric will calculate the time between the work item creation and the latest status change to any of the "done" statuses respecting your Time to Done SLA timer.

If you are using your Jira instance with the defaults (there is Time to Resolution SLA; there is no Time to Done SLA; Cancelled, Resolved and Closed are all considered as done):

• "Time to resolution" respects the SLA calendar, thus the "Resolution SLA success" shows the success rate as expected.
• "Time to done" shows wall-clock timing for the same work item set, while "Time to Done SLA Success" will not show anything since there is no SLA defined.

To see how Time to Done SLA can be defined, please review the sample below.

"Issues in error" are the work items for which we hit fetch failures even after we perform re-try operations. If you see a number of issues in error, please try running the report again and if it persists, please contact us at support [at] solverox [dot] com - your expectation should be to see 0 errors per reports.

1. Either your SLA calendar does not count the time because the work items you investigate are outside of the SLA calendar they are tied to, thus the timer is not working (normal).
2. Or you have a very sophisticated AI Agent, like TS AI Agent by Solverox, which listens to your Jira queues, navigates through your work items, and provides near-instant replies to your customers' questions.

None of these two? We are always here to help: support [at] solverox [dot] com

Many organizations want to see the time spent on work items according to different departments, or their company vs their customers. Here, you can provide basic mathematical equations for your table/graph labels:

my bucket name that will show as graph label = Average of (status_1 + status_2 + ... + status_n)

Here are some examples to build your table/graphs (you can create up to 10 different labels):

• Waiting for Customer = waiting for customer -> shows how much (average) your work items wait for customers to come back to you.
• Waiting for Solverox Support = Waiting for support -> shows how much (average) your work items wait for your support team.
• Waiting for Solverox Development = Escalated + In Progress + pending -> shows how much (average) your development/test/product teams work.

Let's say we focus on two work items, SUPPORT-1 and SUPPORT-2. Let's assume SUPPORT-1 moved to "waiting for support" twice, and it stayed in this status first for 6 minutes and second for 4 minutes, so SUPPORT-1's "waiting for support" total is 10 minutes. SUPPORT-1 never moved to "pending". SUPPORT-2 moved to "waiting for support" only once (30 minutes) and to "pending" only once (20 minutes).

This is what we expect to see in the graph: SUPPORT-1 waiting for support = 6m + 4m = 10 minutes; 0 minutes for pending. SUPPORT-2 waiting for support = 30 minutes; 20 minutes for pending.

The average you would see for "waiting for support" = 10 minutes for SUPPORT-1 + 30 minutes for SUPPORT-2 = 40 minutes / 2 work items = 20 minutes.

The average for "pending" = 0 minutes for SUPPORT-1 + 20 minutes for SUPPORT-2 = 20 minutes / 2 work items = 10 minutes.

For "ticket creation date" method you see these times in the period the ticket is created. For the "Event Based" method you see these times in the period where the work item is resolved.

This report gives you the ability to see the distribution of up to 2 custom fields over the JQL period bucketed by ticket creation date. The most common custom fileds our customers use are:

• "SLA type" to report the service quality for different support packages
• "Account Managers" to report the service quality for the accounts of different Account Managers or Business Development Managers
• "Geographies" to report the service quality for the groups of customers in different Geographies

Note: For custom fields, we have a hard limit of 256 characters for the lenght of that custom field - this means that if you expect to have entries longer than 256 characters for your custom fields, you should expect your results to be truncated to the first 256 chars in the report output.

What you see is the percentage of the tickets that turned back to a "non-done" status after it reached one of the "done" statuses. This metric is always recorded in the period where the work item was created - regardless of reporting method.

Modern browsers and operating systems may reduce or pause background activity for tabs that are minimized, inactive, or running behind other applications. During report generation, the application maintains a continuous real-time connection with the processing service to receive live data and progress updates.

If the browser tab becomes inactive, the browser or operating system may throttle or suspend these background processes. This can interrupt communication with the server and may cause report generation to fail, stall, or display connection-related errors.

To ensure reliable report generation, keep the browser tab open, visible, and active until the report has been completed.

The time required to generate a report depends on several factors, including current Atlassian infrastructure load, the complexity and customization level of your Jira instance and the report itself being generated. Generation times may vary significantly between environments and report configurations.

If you cannot wait for a long-running report to complete, consider refining your JQL to reduce the matching number of work items included in the report. This can significantly reduce the report generation time and allow you to view the results sooner.

Note: You can safely browse this help page while your report is being generated. Feel free to use this time to familiarize yourself with this application.

"The browser could not fetch the report data. Please run the report again."

The most possible reason is that the browser tab/window was not active during report generation. Please see Why should I keep the browser tab open and active during report generation? for more details.

"These statuses were not found in Jira:"

The most possible reason is that the statuses you want to report on are not available or you do not have permission to view them. Please check the workflow definition for your Jira project to see if the statuses provided exist. Also make sure that you do not use quotation marks or any other characters as this can cause the statuses to not be found. The format should match exactly the status names in Jira, including spaces and capitalization, as shown in the tooltip text just below the input field.

"These custom fields were not found in Jira:"

The most possible reason is that the custom fields you want to report on are not available or you do not have permission to view them. You can either check the Jira admin page to see if the custom fields exist, or export a sample issue as CSV and check whether the custom fields appear in the columns of that sample issue.

All the minor updates to this application are pushed automatically.

For the major updates to take effect, one of the Jira Admin users needs to update this application manually.

Please contact your Jira Admin, ask them to go to "Connected Apps", find "Metrics and Reports", click on "view app details" and click on "Update".

All clicks to update this application will be:

"settings" icon on the top right of the Jira UI -> marketplace apps -> manage apps -> take me there -> connected apps -> Metrics and Reports for Jira Service Management -> view app details -> UPDATE

• Users can view reports only for Jira work items they are authorized to access. As a result, reports generated by different Jira agents may vary even when the same JQL query is used.
• After installating this application, the application will be accessible from all JSM projects within your Jira instance. While the application can be opened from any JSM project, reports can still include work items from other JSM projects as well. This design provides the flexibility to manage reporting from a centralized location. If you want to generate reports for a specific JSM project only, you can restrict the scope using JQL with project = Your Project Name.

Solverox provides consultancy on Jira, calendars, SLAs, Automations or other subjects that you may need to get the maximum benefit from the applications that Solverox builds. Please contact us at sales [at] solverox [dot] com

This application is currently available free of charge, but we plan to transition to a paid model in the future. When this happens, we will have clear communication on the pricing policy and grace period for the existing users.

Metrics and Reports (JSM) is built using incredible open-source software. We are grateful to the following projects:

• React (MIT License) - UI Framework

Full license notices for these components are available in their respective public repositories and documentation.

Please reach us at support [at] solverox [dot] com.

Please visit us at solverox.com