How to count the amount of times a JIRA issue has been in a specific state?

Question

In my project one of the metrics we want to use is the amount of times a JIRA issue is moved back from "QA" to "Development." We call it "comeback rate."

Looking for % of items that were resolved by developers and then reinstated later by QA (or whoever) due to a defect in the fix or enhancement.

My boss wants to use this as a measurement of development process quality.

I can filter for items that are currently resolved or reinstated, but once an item is resolved again I can't figure out how to see this in a filter or report.

Example of what I would like:

• Year 2017 - 400 items resolved - 80 items were reinstated at least once - 4 items were reinstated more than once.

• Year 2018 - 460 items resolved - 60 items were reinstated at least once - 2 items were reinstated more than once.

In above example, my boss will think: "Good job developers! You decreased your comeback rate!" and we will rejoice.

Thanks!

Answer 1

I would rather tackle the source of this "comeback"

On the face of it, it looks to me that your process needs some basic changes. Do not mark a ticket as resolved unless:

• QA tests it and gives it their approval.

• Stakeholders ('whoever') test it and give it their approval.

Tools for unit testing, automated testing and Continuous Integration (CI) are readily available in all the major coding platforms. Evaluate using these as well.

Any effort on these lines will be far more valuable than major effort in measuring the results of process deficiencies.

Answer 2

Got a similar problem and got curious about how to obtain it.

• There's plugin alternatives, such as Limetrees.

• For API alternatives, you'll need to dig into each ticket to check for this. You'll need to search for the Jira and use the expand=changelog option to have the info you need. Source: https://community.atlassian.com/t5/Answers-Developer-Questions/API-for-get-transition-and-history-for-issues-by-REST-API/qaq-p/503108

---

API Example: https://yourJiraServer.com/jira02/rest/api/2/search?jql=key=JIRA-01&expand=changelog

It'll return a JSON with something like...

              "items":[  
                 {  
                    "field":"status",
                    "fieldtype":"jira",
                    "from":"3",
                    "fromString":"Closed",
                    "to":"10010",
                    "toString":"Reopen"

... and you can count the amount of occurences of "toString":"Reopen" (or any other state you're interested on).

Answer 3

Use a SQL Query

An answer on Stack Overflow addresses how to query for re-opened issues. I won’t vouch for this particular example, but it certainly shows that reopened tickets can be found through a SQL query. Consider the following example:

tickets = project_name AND status WAS Reopened

Note that I haven’t tested this solution myself because I don’t have a relevant data set, but it (or something similar) should yield the results you’re looking for.

See Also

• https://confluence.atlassian.com/jirakb/how-to-list-all-the-issue-status-transitions-for-past-x-days-with-issue-key-from-database-in-jira-747832195.html
• https://stackoverflow.com/questions/46058405/is-there-a-way-to-count-the-number-of-reopened-tickets-in-a-jira
• https://developer.atlassian.com/server/jira/platform/database-issue-status-and-workflow/
• https://www.tutorialspoint.com/jira/jira_advanced_search.htm

Address Underlying Process Issues

However, to expand on @Ashok’s points from his answer, tracking re-opened tickets is an agile implementation smell that indicates one or more of the following:

1. The lack of a truly cross-functional team.
2. A lack of continous integration.
3. A lack of adequate regression testing.
4. A failure to treat change as new work.
5. Functional siloes, where testing is divorced from development.
6. A culture of blame, where “you fixed it wrong” is a more important message than “let’s collaborate on fixing it right.”
7. A development process that isn’t truly iterative.
8. A missing or inadequate Definition of Done.

Unless you address the underlying process problems, tracking re-opened tickets as a first-class metric hides the organizational dysfunction, and continues to place unwarranted responsibility on the developers without sufficient collaboration with testers and stakeholders.

Agile implementations are a team sport. Testers and stakeholders are most definitely part of the team, and must actively participate in the process rather than just passing judgement on the results at the end.