How do I find tasks that have been in review twice? And does it make sense as a metric?

[Giulia Carletto]

Hello all!

I work as a product manager in a full-stack team. I have noticed that tasks (frontend, backend or design) have been going back and forth in the review column.

The team member works on it (in progress) -> sends it for review (in review) -> when someone reviews they usually ask for changes -> back in progress -> back in review -> the reviewer asks for more changes -> back in progress -> back in review -> approved. (here continues with testing etc)

If the task is especially complex or the engineer especially junior I can totally see how a double review is needed, but my hunch is that this happens too often.

Is there a filter in Jira that would allow me to find all the tasks that have gone through this double review process?

And a more open question: is it a metric that you use/ would use to measure productivity or thoroughness?

[Valeriia_Havrylenko_SaaSJet]

Hello @Giulia Carletto   👋 

As an alternative , I guess you can try Time in Status for Jira Cloud (developed by my SaaSJet team) with 7 types of status time reports. 

For your exactly need we have Status Count report or Transition Count report

The Status Count report shows how many times an issue has been in each status.

Chart view of report:

The Transition Count report shows how many times an issue has moved between all statuses in the workflow.

Chart view of report:

Add-on has a 30-day free trial version and free up to 10 users. 
Please, let me know if you have any questions

Hope it helps 😌
Valeriia

[Bill Sheboy]

Hi @Giulia Carletto 

You could use the JQL operator CHANGED to see if the status changed from / to particular status values at least one time.  Counting the number of changes is more difficult with out-of-the-box Jira features.

For example, let's assume your workflow is: To Do > In Progress > In Review > Done

You may find issues which moved backwards in flow with this JQL:

project = myProjectName AND status CHANGED FROM "In Review" TO "In Progress"

And you could add the BEFORE, AFTER, DURING, or ON predicates to refine that by timeframe.

Here is the documentation on the CHANGED operator: https://support.atlassian.com/jira-software-cloud/docs/jql-operators/#CHANGED

And once a specific issue has been identified as moving backwards, the team could review the issue history to see the full progress events and repetition count.

Your question about the value of this measure depends upon your team and the frequency of this occurrence.  Backward flow is a "smell" of a problem, and so if the team regularly has retrospectives to examine cycle time, outliers and unusual events, and creates experiments to improve they are already seeing this.  Better still, if someone raises their hand and "halts the line" when this backward flow occurs, they will have a better understanding to respond quickly and update plans for the remainder of their sprint / iteration.

For me, I have regularly used that measure, just-in-time at retros (as noted above), and for workshops to perform value stream mapping to improve flow across multi-team work.  (For example, improving incident management across all tiers.)

Kind regards,
Bill

[Mehmet A _Bloompeak_]

Hi @Giulia Carletto

You can track how many times an issue goes into Review status and if there is an unusual number of transitions, you can dig into the reasons and find some improvement areas. Therefore, I think it is meaningful to use that metric to improve team performance.

If you prefer to use a marketplace app, you can try Status Time Reports app developed by our team. It mainly provides reports and gadgets based on how much time passed in each status.

Here is the online demo link, you can see it in action and try without installing the app. For your case, you can have a look at Status Count And Entry Dates report. Entry date(see In Development, Ready for Testing, In Testing, In Development columns.) is status transition date and status count(see #In Development, #Ready for Testing, #In Testing, #In Development columns) is how many times an issue is entered to this status.

• This app has a dynamic status grouping feature so that you can generate various valuable reports as time in status, time in assignee, status entry dates and status counts, cycle time and lead time, average/sum reports by any field(e.g. average in progress time by project, average cycle time by issue creation month).

• You can search issues by Project, Issue Type, Status, Assignee, Issue Creation/Resolution Date(and any other Date field) and JQL Query.
• Status durations are calculated according to the working calendar you define. Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days.
• You can set different duration formats.
• You can export reports in CSV file format and open them in MS Excel.
• You can also add this app as a gadget to your Jira dashboards and reach “Status Time” from Issue Detail page.
• You can enable/disable access to Status Time reports&gadgets and Issue Detail page per project, users, groups or project role.

For further details, you can have a look at Status Time Reports How to Videos.

If you are looking for a completely  free solution, you can try the limited version Status Time Reports Free.

Hope it helps.

[Carla Ann Rowland]

Hi,

As a project manager and team lead tracking the number of times status tracking of items in development is good. As others have mentioned a "benchmark" is good to establish. That way it can point out bottlenecks and SLAs can be adjusted for more correct timelines for development.

Tracking the history of the issue in and out of a status would be using a was or change status and you can drill down to who moved the issue.

[Emre Toptancı _OBSS_]

Hello @Giulia Carletto

Going back and forth between InProgress and Review is some kind of "reopen" action and any reopen should be inspected if you suspect a problem.

As others have pointed out, you can use JQL's CHANGED operator to find issues that was moved from one status to another at least once, but counting reviews is another story. You can try counting that with a custom field and some post function but that requires custom configuration and will work only for future issues.

The data needed for that is already available in each issue's history. I suggest you use a marketplace app which provides such reports based on those histories.

If you are OK with using a marketplace app for this, our team at OBSS built Timepiece - Time in Status for Jira for this. It is available for Jira Server, Cloud, and Data Center.  

Time in Status mainly has several types of time reports (showing how much time each issue spent on each status, assignee, or group) but the app also has Status Count and Transition Count reports. These reports show how many times each status and each transition was used by each issue.

For Status Count report, you can even sort and filter the report data based on status counts. In other words, you can easily find the issues that visited the Review status more than once, twice, etc.

For all numeric report types, you can calculate averages and sums of those values grouped by the issue fields you select. Grouping by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend. (The screenshot below shows a trend report sample for durations but you can do the same for status or transition counts)

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well. It supports both Company Managed and Team Managed projects.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.

And the app has a REST API so you can get the reports from Jira UI or via REST.

  

Timepiece - Time in Status for Jira

EmreT

[Trudy Claspill]

Hello @Giulia Carletto 

There is not a native filter function that will let you select issues based on the issues having been in a particular status more than once.

You could use a custom field to count the number of times an issue is transitioned to a specified status, and then filter based on the custom field. You would populate the field with an Automation Rule that would run each time the issue transitioned to that specified status.

There are third party app that can get you that metric also, I believe.

As to whether the metric is useful, I would apply the Goal, Question, Metric method to the problem. You can find a lot of information on that method through an internet search.