Cycle Time and Lead Time in Jira: Productivity Measurement with Two Critical Parameters

[#1]

This article is about what cycle time and lead time is and how you can use these metrics in Jira to measure your team's productivity and get useful insights.

Measuring productivity is crucial to understand how well a team is performing in meeting customer needs and reaching its targets. The team may be performing at its highest potential or it may be performing what can be considered as normal or it may be performing below its potential. In either case, you need to continuously monitor the productivity of the team, analyze and understand the dynamics behind it and take necessary actions.

In order to measure productivity, it is important to choose the right metrics and base your monitoring and analysis efforts on these metrics. In Agile framework, there are two critical parameters named as cycle time and lead time often used to measure productivity.

Cycle time is the time it takes for the team to start working on an issue and complete it. In other words, cycle time starts when an issue is moved to “In Progress“ status and ends when the issue is moved to “Done” status. A frequently asked question is “Does cycle time include wait time?” The answer is “Yes”. After the team starts working on an issue, they may be waiting for a configuration to be done, a problem to be solved, data to be created, someone in another team to collaborate, etc., in order to proceed with their work. Since this wait time is spent while the issue is in “In Progress“, it is included in the cycle time.

On the other hand, lead time is the time interval between the moment an issue is requested to the moment it is completed. In other words, lead time starts when an issue is added to the Backlog in “New“ status and ends when it is moved to “Done“ status. In real world, after an issue is requested it may be staying in Backlog for a while before the team picks it up and starts working on it. This may be due to several reasons. The team may not have capacity to start working on the new issue, the priorities of the business team may change, an impediment may occur preventing the execution of the issue etc. If you are asking if lead time includes this “waiting in the Backlog“ time, the answer is “Yes”.

Companies mostly aim to find ways to decrease cycle time & lead time and minimize the difference between the two. Now the next and more important question is “How can you measure cycle time and lead time effectively?” One option is to use JIRA’s built-in Control Chart feature.

“The Control Chart shows the Cycle Time (or Lead Time) for your product, version, or sprint. It takes the time spent by each issue in a particular status (or statuses), and maps it over a specified period of time.”

An alternative option is to use Status Time Reports developed by our team, Bloompeak, that provides comprehensive and more detailed reporting and analysis capabilities on measuring cycle time and lead time in Jira.

Status Time Reports app mainly provides reports and gadgets based on how much time is passed in each status. It has a dynamic status grouping feature so that you can generate various valuable reports as the following:

• time in status

• time in assignee

• cycle time

  • cycle time for each individual issue

  • average cycle time of all issues

  • cycle time by assignee or project and issue type or sprint or component or issue creation week/month

• lead time

  • lead time for each individual issue

  • average lead time of all issues

  • lead time by assignee or project and issue type or sprint or component or issue creation week/month

Here is sample reports that you can use for measuring cycle time and lead time.

• Cycle Time for Each Individual Issue

• Cycle Time by Assignee

  

• Cycle Time by Issue Creation Month

  

• Lead Time for Each Individual Issue

  

• Lead Time by Sprint

  

• Lead Time by Component

  

You can use either default 24/7 calendar or your working calendar (excluding non-working time). If you choose to use your working calendar, your working schedule will be taken into account. That is, lead time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM will be reported as a few hours rather than 3 days.

If you continuously monitor lead time and cycle time and analyze the results, it provides you valuable insights on identifying bottlenecks in your product life cycle, understanding your improvement areas and increasing your team’s productivity.

We hope you find this article helpful in giving some insights on measuring cycle time and lead time in Jira. 

[John Scott]

Thank you for this information 

[rcdpanjaitan]

Hello, I can't find "Cycle Time" and "Lead Time" on my JIRA (currently still using the non-cloud).
Does it require another plugin? can not by configuration only?

[Mehmet A _Bloompeak_]

Hi @rcdpanjaitan ,

You can create "Cycle time" and "Lead time" reports by grouping your statuses.

Here are the videos showing how to group your statuses to get

• cycle time: https://www.youtube.com/watch?v=jMCFB2gitso
• lead time: https://www.youtube.com/watch?v=--p97i66Fw8

You can check our channel which shows how to create various reports with Status Time Reports app. https://www.youtube.com/channel/UCdBF87KKS6HRMFvbGYZQHvQ/videos

Hope it helps.

[Lindsay.Singh]

Hello -

To begin with, my company does not use "In Progress" or "Done" in our Jira workflows. We have created our own statuses that are not Jira "out-of-the-box" statuses (for our full workflow statuses, see my attachment below with the groupings I created for Lead and Cycle time columns). 

I created a Lead Time and a Cycle Time grouping column that includes each status we want to report on for Lead Time and Cycle Time, but the resulting variables are not making sense. Some issues do not have an amount in the columns, even though the history of these individual issues shows that they were moved through each status included in the grouping I created. Also, when filtering by the status "Closed" (which is our "Done"), the time displayed is not accurate. For example, the time stated was 3h 33m, but when looking at the story's history, it was created (status = "Open") on July 19, and was completed (status = "Closed") on July 25.

For accurate results, do we have to use out-of-the-box Jira statuses? Or am I setting this up wrong?

How is the time for each status calculated?

For example, when viewing a column with "Closed" status:

* Is it the total time from initial creation ("Open") to the date/time the issue was moved to completed ("Closed")?

* Or is it the total time from the previous status ("In UAT") to the date/time the issue was moved to completed ("Closed")?

I appreciate any help you can provide!

FYI - we are trying to calculate Lead Time differently than the norm, so here is an example of that for reference:

[Mehmet A _Bloompeak_]

Hi @Lindsay.Singh ,

Thanks for the detailed explanation.

You do not need to use out-of-the-box Jira statuses.

The "Closed" column shows how long the issue stayed on "Closed" status. It displays

• neither the total time from initial creation ("Open") to the date/time the issue was moved to completed ("Closed")
• nor the total time from the previous status ("In UAT") to the date/time the issue was moved to completed ("Closed").

In your "Cycle Time" group, you should remove "Closed" status and "Groomed" status because in your workflow Cycle Time begins when development starts and it finishes when the issue transitions to "Closed" status. You shouldn't be interested in the time passed in Closed/Groomed status.

Hope it is clear. If you have more question, we can have an online meeting, feel free to contact us via support@bloompeak.io 

[Travis Webb]

Hello, I am working on a cycle time report, and I think I get this.  Basically, it adds all the status sums together that I group, correct?  For us, it ends with one of two states.  So, would I make a group for each?  And about "on Hold;" we remove the "on hold" from our cycle time. If I just leave "on hold" out as a status that should work, correct?


Group cycle 1 
In backlog > In Dev> ready for UAT> NFR.

Group cycle 2
In backlog > In Dev> ready for UAT> NFR>UAT.
No "blocked." in either so it is not calculated in.

Group Lead
In backlog > In Dev> ready for UAT> NFR>UAT> Comp>Blocked> Done

Does that work?

Thank you, 

[Mehmet A _Bloompeak_]

Hi @Travis Webb,

Thanks for the detailed explanation.

Your understanding is correct, statuses under the same group are summed. For cycle time, you should exclude "In backlog" status, because  most probably you start working on an issue when it is moved to "In Dev".

---

I guess NFR is "non functional testing". There might be some NFR-only stories(e.g. infra, logging, performance or security improvements) which do not require UAT and these are directly transitioned to Completed status after NFR. In that case there is no need to define 2 different cycle groups. NFR-only story will not stay in UAT status, therefore there will be no additional sum coming from UAT. You can just create 1 cycle group with the following statuses in it.

In Dev > ready for UAT> NFR > UAT

---

According to below general definition of cycle time, you should include blocked and "on hold" statuses. But it is up to you, your preference might be to exclude them.

"A frequently asked question is “Does cycle time include wait time?” The answer is “Yes”. After the team starts working on an issue, they may be waiting for a configuration to be done, a problem to be solved, data to be created, someone in another team to collaborate, etc., in order to proceed with their work. Since this wait time is spent while the issue is in “In Progress“, it is included in the cycle time."

---

For lead time, you should exclude "Done" status, because lead time ends when the issue is done.

Hope it is clear. If you have more question, we can have an online meeting, feel free to contact us via support@bloompeak.io.