Reporting on the number of times a Jira issue transitioned to a particular status can be extraordinarily helpful for tracking metrics like:
Jira issue reopen counts
the number of revisions a story or specification required before moving into development
management approval passes
efficiency in triaging tasks, stories or bugs
QA, testing or other approval failure counts
the number of exchanges required with customers to qualify reported issues
Using Arsenale Dataplane and the ScriptRunner for Jira add-on, tracking these metrics in Jira is simple.
In this example, we'll report on the number of times a Jira issue was reopened. You can easily adapt this example to report on any particular Jira status or statuses relevant to your workflows or processes.
Create a new ScriptRunner custom field ("Scripted Field") in Jira, called "Reopen Count" (or whatever status you'll be tracking). Select Number Searcher for the "Search Template" option for this field, since the field will be returning numeric values.
For report configuration options, set up your report as follows:
Option
Selection
Comments
Time Period
any
Select your dates of interest using relative dates ("Last 3 Months", "This Year") or a custom Start Date and End Date.
Search
any
Select your Jira projects, project categories and filters of interest. Or click on the JQL tab in that field to enter a command using Jira Query Language (JQL).
Value Of
Reopen Count
Select the name of the new ScriptRunner custom field just added.
Date Basis
Resolution Date
Select the date on which each issues' reopen count will be plotted. You might alternatively choose "Created Date", or a custom date field.
Chart Type
Select the Column Chart
Now click on the Run Report button to create your report.
We see a clear report of issue reopen counts across the selected time period.
To better understand what type of issues in this project were most frequently reopened, let's go back to the report configuration page and add Issue Type (Historical) to the Segment By field to break down the results.
Here's what the report configuration now looks like:
Running the report again, we now get the same results segmented by issue type: