Cycle Time Report incorrect following workflow changes?

[Darren Bryant]

I am trying to use the built-in cycle time report and it seems like since I updated our workflow and replaced some status' with others that the timings are incorrect. 

The best example of this is:

Our first column on our board is "Selected", this is where I - the product owner - fill the board with the highest priority items (5 at a time).

The team ignore that status from their cycle time as they've not actually truly begin working on it yet.

Historically they tracked from "In Development", this was replaced with status "Doing" as the team encompasses a UI/UX Designer and Tester and to enable a better representation of their work we altered the board and the flow.

The above Story actually transitioned to "In Development" (which is no longer part of the flow) on 28th April 2020.

It wasn't transitioned to "Done" until June 16th 2020.

So in summary, that 2w cycle time is horribly inaccurate. 

It doesn't "feel" right that because we change the status' and aspects of the workflow, that the cycle chart is completely thrown out.

[Emre Toptancı _OBSS_]

Hello @Darren Bryant ,

If you are interested in a ready built solution, our team at OBSS built Timepiece - Time in Status for Jira app for this exact need. It is available for Jira Server, Cloud and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee or group. You can combine statuses into consolidated columns to see metrics like Age, Cycle Time or Lead Time. All durations can be display in various formats including days, hours, minutes even seconds.

The important aspect of Time in Status for your case is: Its reports work based on statuses, not board columns. Each status duration is shown separately and you choose if you want to combine them and in what way.

The app can calculate averages and sums of those durations grouped by issue fields you select. (For example see the average Cycle Time per project and per issuetype or see the sum of InProgress time per component). 

The app has custom calendar support so you can get your reports based on a 24/7 calendar or your custom business calendar. (This one is important because a 24/7 calendar in most cases shows misleading data. For example an issue created at 16:00 on Friday and was resolved at 09:00 on next Monday seems to stay open for 2,5 days but in terms of business hours, it is only a few hours. You can see this using Time in Status by OBSS.)

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions. Get metrics like Lead Time or Cycle Time.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example see average InProgress time per project and per issuetype.)
• Export your data as XLS, XLSX or CSV.
• Access data via REST API.
• See Time in Status data and charts for each issue as a tab on issue view screen.

Timepiece - Time in Status for Jira

EmreT

[Bill Sheboy]

Hi @Darren Bryant 

Yes, I agree that this reporting solution is not ideal.

This is a complex problem for Atlassian to solve, as they need to roll-up information from the issue logs to compute cycle times, using dynamic option selection (time, status, filter, etc.).  But they do not appear to have versioning for the workflow, board columns, and status mapping in such a manner that they can determine a team's "workflow" at a point in time.  As a result, a measurement starting point is effectively reset when any one of these variables changes.

Maybe one of the marketplace vendor's products can recall the workflow.  I do not know.

We instead built our own cycle time capture, using custom fields and automation rules.  This allows persisting the values with the issues, so no re-calculation on the fly.  Then as workflow evolves over time, the prior measures are not lost or broken.

Best regards,

Bill