3

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!

2
  • btw, reason for 'more than once reinstated' is that it is a clue for thrashing: if developer didn't fix it right the first time it came back to her, then maybe they need serious help. or whatever. Mar 25, 2019 at 23:13
  • Restructured a bit the question to be more generic and less specific to the "comeback" rate, which is not something other projects may have in these specific words.
    – Tiago Cardoso
    Mar 26, 2019 at 15:19

3 Answers 3

2

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.

1

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


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).

0

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.