Lead time and Cycle Time and the importance of Flow in Kanban

[#1]

When discussing the importance of workflow in Kanban, two primary notions come into play lead time and cycle time. What is the difference between them, and how can we measure them?

Lead time is mainly a period. It starts when a request enters the work cycle and is in the "ready to start" phase and ends when the request is "completed."

The following example better illustrates the concept behind lead time:

Let's say you placed a dinner order at 8:00 p.m. and your order gets delivered at 8:30 p.m. your lead time, in this case, is 30 minutes.

It's the period from the moment you placed a request until you got your request delivered.

Cycle time is how much time a resource spends on a task. For example, cycle time starts when a team member processes a request from the "in-progress" status until the "completion" status.

Back to the dinner example, cycle time is when the chef starts preparing your order. Let's say the kitchen received it at 8:10 p.m. You get your food delivered at 8:30 p.m; in this case, your cycle time is 20 minutes. It is the actual time needed to process your order.

How are both times measured?

The main difference between lead time and cycle time is their unit of measurement. Lead time is measured by seconds, hours, and weeks, whereas cycle time is measured by the time spent per task, unit, or process.

What is their relationship, and how can we calculate it?

Lead time = Cycle time x Work in Progress (WIP)

The purpose of this formula is to render the entire process predictable, allowing you to reliably forecast project completion with minimal loss and enabling you to outpace your competitors with faster, more efficient output.

Calculating lead-time vs. cycle time to ensure a better flow

The truth behind the flow of work is not how fast an item moves through the cycle but how smoothly it flows from start to end. And that's what matters. Limiting work in progress is of utmost importance as to why the Kanban method works well. It may sound unrealistic, but limiting work in progress refers to how many tasks can be started at once.

The cumulative flow diagram is one of the most effective ways to calculate lead time vs. cycle time. This diagram helps you: 

•      Track the total number of tasks entering the workflow and gather completed tasks over time.     

•      Shorten gap time between lead time and cycle time

•      Eliminate bottlenecks     

•    Adjust workflow and improve team efficiency

Managing lead time versus cycle time effectively leads to smoother, more efficient workflows. In the process, limiting the time gaps between the start and ongoing phases ensures more predictable and achievable team goals. In addition, defining the work in progress and balancing the initial tasks results in significant added value for the customer.

[Bill Sheboy]

Some ideas for possible readers of this article:

Process Lead Time (also known as Process Cycle Time): the time from when a work item enters a process until it exits.  For example, from when a customer makes a request until delivery is made to the customer. This is measured in units of time.

Cycle Time: a measure relative to a process, from the start of work until completion of a selected set of process steps.  For example, from the start of in-progress work until delivery to a customer.  This is measured in units of time.

Work in Progress (WIP): any work item which has entered a process and not yet exited.  This is measured in counts of work items.

Throughput (also known as Completion Rate or Exit Rate): the count of work items completed in a unit of time.

Little's Law: given several specific criteria and assumptions, this is the relationship between Average Process Lead Time, Average WIP, and Average Throughput:

• Average Process Lead Time = Average WIP / Average Throughput

While considering with these ideas, particularly Process Lead Time and Cycle Time, "[both] terms are very dependent on one's perspective: one person's Lead Time is another person's Cycle Time and vice versa."  Consider your entire value stream and context when deciding both measuring and experimenting with actions.  Actionable Agile Metrics for Predictability: An Introduction, by Daniel Vacanti.

For additional information, please see sources from Donald Reinertsen, Daniel Vacanti, David Anderson, Mary and Tom Poppendieck, Atlassian, the Lean Enterprise Institute, Scrum.org, Six Sigma, Wikipedia, etc.