📈 Comparing Jira Reporting Apps: Closed vs. Reopened Tickets 🏆

Patricia Modispacher _k15t_

 

This article was written by our agile reporting specialist and Product Owner of Report Builder: Rustem Shiriiazdanov.

 

 

---

 

 

In the world of IT service management, the efficient closure of support tickets is paramount. Yet, what if those tickets, once closed, rise up again because the initial resolution didn’t quite hit the mark? The need to monitor and enhance this process is where the Closed vs. Reopened issues report comes into play. After all, Reopened Issues are the sequel we didn’t ask for (as we explained in our previous article)

 

A specialized ITSM called Closed vs. Reopened report equips you with the essential tools to track, analyze, and ultimately improve your service management.

Let’s navigate the world of Jira reporting and discover the tools that can transform your data into actionable intelligence.

 

How to track closed and reopened issues in Jira? 🧐

Unfortunately, Jira Software does not have a built-in report specifically named “Closed vs. Reopened Issues.” To create such a report in Jira, you would typically need to use workarounds and custom reporting configurations.

1️⃣ First workaround

1. Ensure that you have the “Reopened” status defined in Jira project configuration.

2. Use JQL to search for issues that have ever been in the “Reopened” status.

3. Export the issues to other tools for building graphs, or use the Average Time in Status graph from Atlassian.

4. Analyze the data and make decisions.

Pros:

• Provides a simple and straightforward approach.

Cons:

• Requires manual labor.

• Requires introducing a new status.

• Requires non-Atlassian ecosystem apps for analyzing the data (cannot calculate “Reopen rate” automatically).

• Unable to determine how many times each issue has been reopened.

 

 

2️⃣ Second workaround

You could also try to use the Jira Service Management built-in Time series report.

1. In Jira Service Management, you can set up a Jira report to track the number of issues closed and reopened over time. To do this, you need to create a report that includes two date series:

   1. Resolved Issues in statuses such as closed, Closed, done, etc.

   2. Resolved Issues in the same statuses but have also been in the “Reopened” status (if this status exists in your workflows).

   The report will typically look like the example shown below:

Jira Service Management Report against Closed vs Reopened issues

The default report in Jira doesn’t offer insights into the rate of Reopened Issues, which you will need to calculate separately. Additionally, it does not provide any information about tickets that have been reopened multiple times. Furthermore, if the “Reopen” status is absent from your workflows for some reason, it will be quite challenging to quantify the occurrence of reopened cases.

 

 

3️⃣ Third workaround

Yet another option is to use Jira automation (or Jira Script runner) to calculate the number of reopens per Jira issue.

Pros:

• Enables counting the number of reopens per issue.

• Does not require new statuses to be introduced.

Cons:

• Involves creating a new custom field.

• May necessitate the use of Script runner if Jira Automation is not viable for some reason.

• Still requires a separate tool to generate graphs using collected data, as it cannot calculate the “Reopen rate” automatically.

Thus, despite having powerful features to create workarounds for the reopening rate of issues, Jira does not allow for comprehensive reporting on this metric out of the box. The great thing about the Atlassian ecosystem is that we can find various reporting tools specifically designed for this purpose! Let’s take a look at them.

 

 

---

Jira apps to monitor closed vs. reopened issues compared 📊

 

You could use many apps to report against ticket Reopens. Since issue reopens case is always related with status and status category change, we selected a number of popular Jira reporting apps allowing you to report against statuses, time in status and transitions from one status to another. We will now look at the selected applications together:

 

 

EazyBI by EazyBI

Make sure you have established the required scope of Jira projects to be imported into EazyBI as a data source. Don’t forget to establish regular updates to ensure that you report against actual data.

No-coding variant: You can create a new Jira report and use the “Transitions from status” pre-defined measure, which will provide you with a view of all transitions that have occurred on your Jira issues. When using this measure in the “Columns” section of the report, and using the “Time” dimension in the “Rows” section of the report, you will get a nice-looking report. You can remove unnecessary transitions to only see those that you consider as reopens.

In our example, we only considered transitions from “Done” to “In progress” status.

You can transform the table into any required chart using EazyBI.

Pros: This method is easy to use for operational analysis and does not require any skills in MDX or coding experience.

Cons: However, it may be difficult to scale for complex workflows with many transitions.

Coding Variant

One possible solution is to define a new calculated measure that checks the number of transitions from the “Done” status to the next statuses using calculated measures. Then, we can define a new measure using MDX.

New “Reopens“ measure defined using MDX

The measure added to the report accurately displays the number of transitions that occurred from the “Done” status to the next statuses. We can verify this by comparing the manually obtained results with the calculated measure-defined ones.

You can also define specific measures to calculate the percentage of reopened tickets or create dimension members to ensure that you only count specific transitions from the “Done” status to other statuses. However, this will require extended coding using MDX. The same applies to calculations of the “reopening rate,” which you will need to define using MDX.

Pros: Very flexible approach, allowing to define tailored metrics, including “Reopen rate metric, %”

Cons: Requires knowledge of MDX.

 

 

Report and Timesheets for Jira by Appfire

To create a Jira report against Jira issues transitions, you may use a combination of fields “Current Status“, “History Status“, “Last transition for status?“. An example of a simple report created with this technique is given below. Please note that you need to use JQL filter or Jira filter to filter issues belonging to specific projects or any other specific criteria.

Pros: Report is created in just a few clicks.

Cons: Such a report cannot calculate the reopen rate in %, hence making you rely on further manual calculations when dealing with massive amounts of issues/tickets.

 

 

Time in Status for Jira – Reports | Charts | Dashboard by SaaSJet

To check what Jira issues were reopened in any of your projects, simply create a report against “transition count“ metrics as shown below. Using this Jira report, you can easily track the number of issues that have been moved from one status to another. This will help you identify any instances where Jira issues with a “Done” status were migrated back to other statuses. In our example, there were no such cases detected.

Note: this report can be created in a table, or bar chart view, and then exported for further analysis.

Pros: Report is created in just a few clicks.

Cons: Such a report cannot calculate the reopen rate in %, hence making you rely on further manual calculations when dealing with massive amounts of issues/tickets.

 

 

Status Time Reports app by Bloompeak

To build Jira reports which will provide us an info about tickets reopenings, we need to click “new report” in the app. Then select the necessary filters and click “Search“.

You will see the list of tickets and transitions happened to them. By default, you see the duration of time Jira issues were in specific statuses. To see how often a ticket was reopened, you need to switch “count“ setting as shown below:

Now, you can see how many times each issue was in every status.

Despite the report not providing information on whether the issue has been reopened until it is closed again (i.e. you can only calculate the report against issues that were finally closed and not stuck in any other statuses), it still provides valuable information on reopens.

Pros: The report is very easy to configure and offers a wide range of filtering options.

Cons: However, it only provides a table view and lacks aggregation functionality. Additionally, it does not have the ability to calculate the reopen rate as a percentage.

 

 

Time in Status by OBSS

The Time in Status application displays the duration of each status for filtered project Jira issues by default. To switch to viewing status transitions, you need to select “Count reports” in the application menu and then choose “Status count”. Additionally, you can select “Transition count” to see the direction of each transition.

Combining the resulting table analysis with “Transition count analysis“, you may understand the number of reopens, and the directions of the actual transitions during reopens.

A huge advantage of “Time in Status“ app is a capability to see graphs of the statuses.

Overall, this app also provides a flexible, yet easy way to report against issues reopenings.

Pros: Super-easy to configure the report, with a lot of filtering options, and the capability to build graphs.

Cons: No aggregation across multiple Jira issues over time, so it is not possible to calculate the reopen rate in percentage.

 

 

Report Builder for Jira by Actonic

Report Builder has a dedicated “Closed vs. Reopened” report, which provides information on the number of Jira issues created, reopened issues, and the reopening rate as a percentage.

The “Closed vs Reopened” ratio is calculated by comparing the number of closed tickets to the number of reopened tickets. This ratio offers insights into the effectiveness of ticket resolution, with a higher ratio indicating a lower rate of reopened tickets and suggesting better overall process management performance. Monitoring and analyzing this ratio helps identify areas for improvement, implement preventive measures, and ensure thorough resolution of tickets on the first attempt.

Actonic’s “Closed vs Reopened Report” also provides users with a Data Source table that enables quick analysis of when the reopening occurred, what the exact transition was, and provides a supportive comment to explain if the transition is counted in the Jira report itself.

If necessary, you may choose to only keep the graph displaying the rate of reopened tickets as a percentage. This will hide the numbers of actually closed and reopened tickets themselves.

As a Manager, you may also be interested in getting a helicopter view on the numbers of tickets being ever reopened, rather than know ever reopen case. To fulfill this need, simply click on “Count multiple close and reopens only once per issue” and your task will be completed!

Pros: 

• Very easy to configure

• Provides reopen rate in percent metric, as well as all the necessary source data for a deeper analysis.

Cons: Limited visuals support: Bar charts, line chart and supporting table views.

 

---

 

The Jira reporting app comparison at a glance 🔍

 

 

App	Calculate reopens	Calculate reopens rate, %	Additional requirements
EazyBI			MDX scripting knowledge to create percent report
Report and Timesheets for Jira
Time in Status for Jira
Status Time Reports
Time in Status by OBSS
Report Builder

 

All apps were tested without custom workflows, where reopened issues end their lives in the “reopened” status. We aimed to reproduce the typical business flow where any issue ends up in “Resolved” or “Closed” status after it has been re-resolved since reopening.

 

---

Conclusion 📊

In the realm of Jira reporting, Atlassian Marketplace offers a diverse selection of apps to cater to a multitude of needs. While the apps showcased here represent just a handful of the available options, they demonstrate the versatility of reporting solutions within Jira.

What's your favorite?

 

 

Emre Toptancı [OBSS]

Hello @Patricia Modispacher _k15t_ ,

Emre TOPTANCI from OBSS here. We are the makers of Timepiece - Time in Status for Jira app you mentioned in your article.

Thank you very much for such a comprehensive article. I am sure many community members will benefit from it.

I'd like to add something: Timepiece - Time in Status for Jira offers aggregation options. You can use the Report Options button on the toolbar to switch from a List report to a Sum or Average report. With this aggregation option, you can get an overall average or you can select some Group By fields to group your issues. For example, you can get reports grouped by project, issue type, etc.

The best part is, the Group By field selection contains options for parts of date fields. You can select them to group your issues by date (created date, updated date, resolved date, or any other custom date field) and see the trend over time.

Here is the documentation page for the aggregation reports:

https://dev.obss.com.tr/confluence/display/MD/TiS+Cloud+-+Report+Options

... and we also made a Youtube tutorial video showing this aggregation function in action.

EmreT