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

[Olexiy Artemenko]

Hi, @Petru Simion _Simitech Ltd__ !

You've raised an important question because measuring those metrics is not as obvious as it may seem.

We've recently launched the Cycle Time Charts app, which allows you the following:

1. For cycle time, flexibly configure the cycle start and end:

2. For lead time - only the end:

This means you can configure it to measure any cycle you want.

On top of that, we recommend users define what exactly they want to measure - the cycle time or time in specific status or statuses because it's different metrics.

Let's see how it differs in the example with one "waiting" status marked as a red rectangle on the timeline:

The app allows measuring both metrics for one or several statuses:

@Petru Simion _Simitech Ltd__, what's your opinion? Can those advanced configurations and charts solve the problems you raised?

We would be happy to receive your feedback on the Cycle Time Charts app, which is available on both Jir platforms: Cloud and Data Center. 

[Vitalii_Bobak_SaaSJet]

Hi and great question @Petru Simion _Simitech Ltd__ 

The calculation of Cycle Time and Lead Time indeed requires flexibility to adapt to varying workflow designs, and simplistic assumptions often fail to capture the nuances of real-world processes.

For this need my team developed 2 add-ons. Both Time in Status and Time Metrics Tracker offer robust solutions to address these challenges, each with distinct advantages:

---

Time in Status

Time in Status allows you to calculate both Cycle Time and Lead Time with customizable configuration options that adapt to your unique workflow. Here's how:

• Customizable Status Selection: You can include all necessary statuses to calculation, allowing you to account for workflows with multiple starting points or delivery statuses.

 

• Reports Flexibility: Reports can be tailored to reflect specific statuses, time periods, or teams, ensuring that the calculations match your actual workflow.

This flexibility ensures that the app considers the actual design of your workflow rather than relying on predefined assumptions.

---

Time Metrics Tracker

Add-on is particularly well-suited for tracking precise durations between key transitions in your workflow. It provides:

• Custom Time Metrics: You can set up metrics to measure the time between any statuses, capturing nuances like time between multiple "in progress" statuses or between custom delivery statuses.

• Multiple Metrics in One Report: Generate comprehensive reports that reflect several metrics (e.g., Lead Time, Cycle Time, Wait Time) side-by-side.
• Visualizations and Alerts: Enhance understanding with visualizations and optional alerts for exceeding predefined time thresholds.

With add-on, you can create metrics tailored to your unique workflow and export the data for deeper analysis if needed.

---

You can also book a live session or contact us at Support - we'll help you with add-ons. 

Add-ons developed by my team.

I hope you find this helpful 🚀

[Gizem Gökçe _OBSS_]

Hello @Petru Simion _Simitech Ltd__ ,

Hello,

You're absolutely right that workflows can vary greatly, and simplistic assumptions about statuses often fail to capture these nuances. Accurate Cycle Time and Lead Time calculations should consider:

• Custom starting and ending statuses.
• Exclusions for pause statuses (e.g., "On Hold").

Timepiece - Time in Status for Jira, developed by my team at OBSS, solves these challenges by allowing full customization of metrics. It adapts to any workflow design and provides precise results tailored to your needs. For this you can use the Duration Between Statuses report type which shows the duration between two specific statuses. This report type also allows the user to exclude the times for "pause" statuses. 

Timepiece is available for both Jira Cloud and Data Center. Let me know if you’d like help setting up this report or need more information! If you wish, you can also schedule a live demo. We will provide a comprehensive overview of the application and address any inquiries you may have.

Hope it helps,

Gizem

[Mehmet A _Bloompeak_]

Hi @Petru Simion _Simitech Ltd__,

I agree with you, each project can have different workflow and apps cannot calculate cycle time and lead time without knowing which statuses should be included in calculation.

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. In this app, you can select and group the statuses that you want to include in your cycle time and lead time calculation.

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 Cycle Time for Each Issue and Lead Time for Each Issue reports.

For further details, you can have a look at Cycle Time For Each Issue Report and Lead Time For Each Issue Report how-to videos.

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

If you have any questions, feel free to schedule a demo with us.

Hope it helps.

[Hannes Obweger - JXL for Jira]

(Deleted)

[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?