Lead and cycle time

Lead and Cycle Time – How to Use the Kanban metrics

Being one of the Agile frameworks, Kanban offers a way for teams to organize and track project progress on a visual task board. Kanban board is the main, but contrary to what some believe, not the only tool used in Kanban. WIP limits, priority columns as well as lead and cycle time aim to help and guide Kanban teams in the management process. While most are familiar with WIP and priority columns, more are still confused about lead and cycle time.

Questions like – what do they measure, how do they differ and how can I use them are too common. So to set the record straight or simply remind you, here is an overview of lead and cycle time.

What is lead and cycle time?

Let’s begin with the definitions:

Lead time is the average time it takes for the team to deliver a product to client since it was requested (appeared in the Backlog).

Cycle time is the average time it takes for the team to complete an item since they started working on it.

So, both of the metrics are averages calculated from all the task data you have on the board. A separate lead and cycle time is calculated for every task, added up and then divided by the total number of tasks. Depending on what type of a Kanban board team uses, this can has to be done manually (in the case of a physical task board) or calculated automatically (if a digital board like Teamhood is used).

lead and cycle time kanban

Teams can choose two ways when monitoring lead and cycle time – they could follow the overall average changes or compare averages from different time periods (for example iterations). If nothing else changes, an increase in either of the metrics could signal a new roadblock or issues in the later project phases. And a sudden decline could mean tasks are of a smaller size, or the process has become more effective.

How to use lead and cycle time?

No matter how you choose to calculate lead and cycle time, tracking it is important. By calculating the averages, lead time gives a good idea on a delivery speed and cycle time provides an indication of the teams speed. Thus following both and noting down changes can give you valuable insight into what is happening with your projects now and might be happening in the future.

Lead time tracks the whole process from the initial request to the product delivery. This includes requirement gathering, analysis and product shipment. Meaning you have a good idea on how long the production of an average item is going to take and can give clients a more accurate guess on delivery. For example, if your average product lead time is 2 weeks and you get a more complicated order, you can safely say the delivery will take longer. How much longer, that depends on your process, but at least you can manage client expectations right out of the gate.

product development process

Cycle time on the other hand focuses just on the production phase of the process. And thus has a bit of a different purpose. Instead of informing your clients on the expected delivery date, it aims to track and signal any issues in the production process. focused only on manufacturing and testing, it can provide great insight into where your own process is lagging and could be improved. It can also signal that new roadblock or issues have arised.

production phase

Lastly, using a combination of both metrics, allows the team to react to changes and adapt more quickly. For example, if a team notices a sudden increase in cycle time, it is safe to assume that the lead time will also grow. However, for clients with sensitive delivery dates, the team can then take action to fast-track other processes outside manufacturing. Thus, still managing to deliver the end result in a timely manner. Moreover, such efforts could lead to finding and applying completely new ways of optimizing the process.

Evolution into actionable Agile metrics

Using both lead and cycle time can give valuable insights into the teams efforts and overall process. However, in 2015 Daniel S. Vacanti proposed that cycle time could be further utilized to gain even better predictability on item completion. While his book called Actionable Agile metrics for predictability talk only about cycle time, no doubt the same approach could be taken with lead time if someone felt the need.

To sum up the idea, Mr. Vacanti proposed that just measuring the average does not give teams the full picture and ways to not only observe, but also control the cycle time. Instead, he proposed to observe the cycle time for all tasks separately and then also calculate the 80th and 95th percentile. By doing this, the teams could know not only the average time it took to manufacture an item, but also how long it will take to manufacture 80% or 95% of items.

release notes version 1.1.0
Actionable Agile metrics in Teamhood

This allowed to give more accurate predictions to clients, knowing that and item is going to be delivered with an 80% certainty is definitely better than 50% certainty right? Moreover, monitoring the numbers on the longest delivery dates, also gave the teams a chance to identify reasons behind them and optimize the process. According to Mr. Vacanti, ideally the difference between the 50th, 80th and 95th percentile should be as small as possible and observing these numbers allows teams to work on reducing them.

Learn more about actionable Agile metrics.


Lead and cycle time as well as actionable Agile metrics are a great way to take control of your Kanban projects. It gives teams a way to monitor what is happening in an otherwise dynamic and changing process. Lead and cycle time focus on the averages and give a way of understanding what clients can expect in terms of delivery dates and what a manager can expect in terms of production speed. While actionable Agile metrics aim to improve the predictability of the delivery date by taking a closer look into the cycle time and the main reasons why it is growing on decreasing.

All in all, these metrics are a great way of getting a deeper understanding of your Kanban projects and improving them when necessary.

Teamhood is a hyper visual project and team management solution that helps companies to streamline business processes and deliver results faster. Teamhood is designed for professional teams seeking efficiency at work and full empowerment of their talents. Teamhood provides workspaces, customized boards with fine-tuned time tracking, collaboration functionalities as well as visual agile metrics reporting.
Teamhood is developed by Eylean, a project management software company since 2011. Eylean products are valued by its numerous customers globally such as Mercedes AG, Festool, Johnson&Johnson, Rabobank and others.

© 2020 Teamhood ® by Eylean. All rights reserved. We use cookies on our website.

Teamhood uses cookies to improve your experience, personalize content and ads, to provide social media features and to analyze our website‘s traffic. By agreeing you accept the use of Cookies in accordance with our Cookie Policy.