Time in status Cycle Time and Lead Time

[Petru Simion _Simitech Ltd__]

There are several apps on the market related to Time in Status that use the terms Cycle Time and Lead Time. However, their definitions rely on ambiguous assumptions about workflow statuses. These apps typically define Lead Time as the duration between issue creation and delivery, and Cycle Time as the duration between when work starts and delivery. They often assume that workflows starts with a "To Do" status and ends with a "Done" status, which is not always the case. In reality, workflows can have varying starting points, multiple "in progress" statuses, and different delivery statuses. Some reports may use the Resolution field to indicate completion, while others rely on witch specific statuses are mapped to the Sprint board left and right columns. Given these complexities, how can these apps accurately calculate Cycle Time and Lead Time? Shouldn't they consider the actual workflow design, including multiple starting points, intermediate statuses, and delivery statuses, rather than relying on simplistic assumptions?

[Danut M _StonikByte_ · Accepted solution]

Salut Petru,

Not sure if you got the chance to look over our Great Gadgets app. It offers some gadgets that lets you measure Cycle Time, Lead Time or time between two different stages/statuses of the workflow, as well as the Time in Status.

These gadgets offer full flexibility in setting-up the start / end of the cycle. So they make no assumptions and do not "hard-code" any existing start status (like "To Do"); you decide what to measure.  

 

Have a look over this article to make a better idea: How to measure Cycle Time and Lead Time in Jira or Confluence with Great Gadgets app 

Danut.

[Petru Simion _Simitech Ltd__]

Salut Danut,

This confirms that a mechanism is required to specify the entry and exit calculation points.

Does your app allow setting the entry and exit point of calculation for each issue type?

Since each issue type can have it's own workflow...

Thanks.

Regads, 

Petru

[Danut M _StonikByte_]

Hi @Petru Simion _Simitech Ltd__,

Not per issue type, but in this case you can use the available options for status categories. 

To measure Lead Time (from creation to resolution) you should set:

Cycle starts: When the issue was created

Cycle ends: When the issue entered a status that has category Done

Category "Done" means any status in done category (those green-colored statuses from Jira like Resolved, Done or Closed). So if you have the right category set on your workflow statuses, these options will work for all issue types. 

Similarly, for Cycle Time (from when the work started to resolution) you should set:

Cycle starts:When the issue entered a status that has category In Progress (this includes any in-progress statuses like In Work, In progress, In Development, etc)

Cycle ends: When the issue entered a status that has category Done

Hope this helps.

Danut

[Hannes Obweger - JXL for Jira]

Hi @Petru Simion _Simitech Ltd__

full agree that definitions of Lead Time and Cycle Time are often simplistic.

If you're looking for more detailed configuration options, you may want to have a look at the app that my team and I are working on: JXL for Jira.

JXL is a full-fledged spreadsheet/table view for your issues that allows viewing, inline-editing, sorting, and filtering by all your issue fields, much like you’d do in e.g. Excel or Google Sheets. It also comes with a long list of so-called history columns that aren't natively available, including time in status, time between statuses, and many, many more.

All these history columns are highly configurable, in that you can specify the exact trigger points for the measurement:

This is how it looks in action:

As you can see above, you can easily sort and filter by your history columns, and also use them across JXL's advanced features, such as support for (configurable) issue hierarchies, issue grouping by any issue field(s), sum-ups, or conditional formatting.

Of course, you can also export your data to Excel or CSV in just two clicks.

Any questions just let me know,

Best,

Hannes

[David Nickell]

Timing is everything :-) ... I just added a screenshot to my website on this very topic.  While I haven't done the METRICS coding yet, it will be easy (and yes, basically free) using the REST API Calls that are done and working. 

By extracting the change log for an issue, you will get every modification of every field.   You can use a filter to limit to status if you want and then use the ID of the changelog to ensure things are in chronological order.  

If you'd like to work on this together, let me know.  (dnickell @ splitdimedata .com) It is the next logical step for me in delivering my own change log solution.   Note -- the screens shown below is from Atlassian data I extracted just yesterday.  Also - time in status is one of MANY metrics we could determine with this data.

NO PLUGINS REQUIRED.   We could port this to Excel or Power BI and have it in your hands by EOD today  :-) 

[David Nickell]

it just occurred to me -- I could publish the Power BI for all to see.  So here it is.  Feel free to play with it all you want and then let me know if you want to take next steps:

REST API Change Log in Power BI 

[Bill Sheboy]

Hi @Petru Simion _Simitech Ltd__ 

Short answer: I recommend reviewing the documentation (and perhaps contacting the support team) for any of the marketplace apps you want to use to learn how they define the measures they provide.

For the apps I have reviewed from the marketplace, including Atlassian's interpretation of a Control Chart, they often allow selection of the entry / exit states for measures using Status values only.  Although, they may have additional examination of workflows to provide loop / rework measures, I have not personally used any of those from addons.

If you have specific capabilities in mind for your measures, I suggest both trying addons before purchase and sending the vendors your specific questions about features.

Kind regards,
Bill

[Petru Simion _Simitech Ltd__]

Thank you @Bill Sheboy .

I read some of the existing app documentation and articles, and  found out the concepts I mentioned. 

I asked the question to determine if there are already established terms for Lead Time and Cycle Time that I might not be aware off. 

Regards, 

Petru

[Bill Sheboy]

I suggest looking at Lean sources for those.  In my experience, Lead Time is unambiguous and Cycle Time varies by context:

Lead Time: duration time from request-made until value-delivered to customer; i.e., "concept to cash"

Cycle Time: duration time between two steps in a process.  For example, Build Cycle Time would be duration time between start and completion of build process steps.  Using value stream practices, this could include looping and rework within those two steps.

[Petru Simion _Simitech Ltd__]

I do understand the definitions. Lead time - duration from request made to delivery and Cycle Time - duration from work started to delivery.  My question is not about that. It is about how can anyone know when the work starts and when delivery is made. This is going to be determined by how the customer defines it's workflows. Since Jira left this open to the customer how could any app know upfront how the customer will set it's workflows?