Measuring waiting times per issue type in JIRA Workflow

[Aneesh Vatedka]

Dear Community, 

I'm looking for possibilities on how to capture waiting times for any issue type in each status of any defined workflow when there is no defined workflow status as "waiting" before or after each status 

For instance, lets consider following WF with defined statuses (as mentioned there is no defined "waiting" status)

Backlog - To do - In progress - Testing - Done

In reality, when the issue is moved from one status to next, the actual work may not begin the moment status is changed. Maybe at later point in time because some previous issue is still being worked upon and the new one needs to wait for its turn. So I want to capture these waiting times in each workflow statuses when the issue is actually waiting and when it is actually being worked. 

Is there anyway we can split this and calculate the mentioned times without defining additional status "waiting" for each stage? I need these to calculate Flow metrics that involves actual work time and waiting time for each issue type. 

P.s. I have already tried to researching  here for old threads with related information. I have found like using the plug-in or app Time in status only helps to find time spent on each status, cycle time etc. I couldn't find where it helps to split identify waiting and work time. 

Thank you very much in advance for comments/information/guidance

Kind regards,

Aneesh

[Bloompeak Support · Accepted solution]

Hi @Aneesh Vatedka ,

As a solution, 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. But you can get time based on any other custom field. Just change the "Report for" select box to your custom field and get time passed on each value of the custom field.

Here is the online demo link, you can see it in action and try without installing the app.

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

Hope it helps.

[Emre Toptancı _OBSS_ · Accepted solution]

Hello @Aneesh Vatedka

You said you already looked at a Time in Status app but I am glad to tell you that Time in Status by OBSS can also give you the report you need. (Hint: We'll be using the super-duper advanced Any Field Duration report type of the app)

First of all, in order to get this report, your users somehow need to enter this data onto Jira issues. You said you don't want to use separate statuses for that. That's fine. In that case, you can create a Select List type custom field with just 2 options: Waiting / Working. Let's call this custom field "Sub Status". (You can also use a label on the issue or any other way to track this. But in any case, you will need something on the Jira issue to represent this sub-state. Let me continue my example presuming you implemented this using a custom field)

When an issue transitions to a workflow status, the value of this Sub Status field should automatically be set to "Waiting" (possible with a post function in the workflow transition). When the user assigned for the job actually starts working, s/he changes this value to "Working". When the issue is transitioned to the next status, the value once again should be automatically set to "Waiting".

As hinted at the beginning, Time in Status by OBSS has a report type named Any Field Duration. This report type can show how long a field (or multiple fields) held each value (or value combination). Once you configure your workflow and process to run as defined above, you can use an Any Field Duration report and select Status & Sub Status fields as History Fields of this report. Then Time in Status by OBSS will show you status times broken down to Waiting / Working times.

(The screenshot below shows a sample Any Field Duration report for Status and Flagged fields combined but you can do the same for your Status and Sub Status fields.)

https://marketplace.atlassian.com/apps/1211756/

EmreT

[Aneesh Vatedka]

Hello @Emre Toptancı _OBSS_ 

Great! This is what I was just hoping to hear :) Thank you. I wasn't aware of the advanced features / possibilities there. The work around with adding additional custom field seems very doable and not much of an additional effort for the end user or assignee considering they have to change sub-status only once when they start working on an issue. If I understood you correctly, next status transition it will go back to waiting. Will definitely try this out. 

Thank you again for crisp, clear and to the point answer. Appreciate that.

Kind regards 

[Ravi Sagar _Sparxsys_ · Accepted solution]

Hi @Aneesh Vatedka 

You can always look in the issue history to know more about the time in current status and either using an app or pulling this data out of Jira (along with issue history) and dumping it somewhere for doing advanced reporting can get you this information.

What I wanted to know is how you would use this information? Jira will only give you information based on someone pressing the transition buttons, they may not actually do the work or update Jira issue on time.

For instance - if you have a simple burn down chart in Jira, then Scrum masters (or PMs) when they conduct daily standups they should look at the chart and try to to unblock the items that cause delay.

Also the cumulative flow diagram already tell this information, if issues are in the same status for a long time then this chart shows it very clearly. It could be due to some issues blocked and just waiting for something.

I hope it helps.

Ravi

[Aneesh Vatedka]

Hello @Ravi Sagar _Sparxsys_ 

Thank you for the hint and provided information. I will look into the issue history part. Yes, CFD is good and in my radar. Will give more or less similar info with E2E information. On a more granular level, like you mentioned respective PO/EOs will review the burn down chart and make sure teams are in the right path. 

I know in JIRA it is only the status transition. We are in process of making everyone use them to document and to get transparency in processes. Having little more detail on the waiting/work time will help us identify inefficiencies in our development or support processes and improve the overall efficiency by reducing unnecessary waiting times. 

Kind regards