Hey there! I’m Sonya Siderova, CEO and founder of Nave. I help project managers figure out how to make their projects more efficient, their teams more engaged, and their clients & stakeholders happier. Today we’re going to take a look at lead time vs. cycle time, and what the difference between them really is.
Tell me if this sounds familiar:
Your client asks you, “hey, can you get this done for me by the end of next month?”
You experience a knee-jerk reaction and find yourself saying, “sure thing, no problem!”
After all, your client is the one paying the bill at the end of the month, and besides: you want to come across as tolerant, kind and polite and strengthen your credibility.
Here’s the thing:
Once you commit to delivering work, the clock of your lead time has started ticking. And there is a big difference between the point in time when your client gives you a request and the point in time when you commit to delivering it. They are not the same thing.
You shouldn’t commit to delivering a request at the moment it arrives. If it’s not critical, the work item should go through your Upstream process before you make your final commitment.
Think about your upstream process as a funnel: not all of the work items will go through, there will be items that you commit to working on now, others you leave for later and another type that you discard altogether.
Remember, your delivery workflow will always be the bottleneck of your system. Your capacity is limited so you should choose wisely what work you initiate.
That’s why it’s so important to make sure you don’t commit to a customer request right away. You have to set realistic expectations.
Why You Need to Define a Commitment Point Before You Start Tracking Your Lead Time
My husband and I have been married for ten years (and counting). Thanks to mutual respect and dedication, our marriage is a happy and stable one.
Imagine for a second, though, if I had said “I do” without really understanding what I was signing up for.
Committing to a relationship means that you have realistic expectations for yourself, and are also able to deliver on your spouse’s expectations.
Managing your projects may not be quite as romantic of a topic, but hopefully this analogy has made my point a little clearer.
In project management, the commitment point is the point in time when you commit to delivering results. Commitment means just that: you are responsible and ready to start.
It’s the point at which the clock starts ticking and your lead time starts tracking.
Don’t promise to deliver a work item until you have selected that work item for your next iteration.
Only then should you move forward, communicate your decision to your client and begin tracking your lead time.
What Is Lead Time in Kanban?
With all that being said, in Kanban, lead time is the time between a request being committed and a work item being released.
Now, let’s go back to that opening scenario for a moment:
Your awesome client asks you, with a hopeful note in their voice, “do you think you can get this done for me by the end of the month?”
Has your client given you a request? Yes.
Has your lead time begun? No.
Your lead time doesn’t begin until you commit and agree to your client’s request.
Until you reach your commitment point, you should not start tracking lead time. Here is the thing – before you’ve committed to a certain task, it’s considered optional. (And yes, feel free to discard options from your backlog if they have diminished in value.)
Here is a Kanban board example, to give you a visual:
In this example, you’ve moved 10 of your options into the “Committed” column. This means they have reached the commitment point and their lead time clock has started ticking. And it stops ticking the moment your work reaches the “Done” column.
In some business contexts, it might make more sense to have your commitment point be at the moment the work has actually started. In this same example, that would be the “Development” column.
What I want you to remember is this:
You decide when is your point of commitment. Your lead time doesn’t begin when your client requests the work – it starts when you commit to doing the work.
You should always go through the process of narrowing down your options before deciding to initiate the work.
What Is Cycle Time in Kanban?
Cycle time begins as soon as your team gets to work on the deliverable.
Using the same example we looked at above, the cycle time clock starts ticking as soon the work is moved to the Development (5) column.
The easiest way to think of it?
Cycle time is a subset of lead time. It’s contained within it.
Want to hear a cool, little-known fact about cycle time that will change your whole perspective?
Both lead time and cycle time are a shape, not a number.
By that I mean, you shouldn’t think of your lead and cycle times in terms of a single number.
Rather, you should think of it as a range of delivery times and the probabilities that come with each of them. This range of time and probabilities forms a pattern, a shape.
A good way to visualize this is the Cycle Time Histogram.
The Cycle Time Histogram shows you the shape of your cycle time frequency distribution. The horizontal axis displays your cycle time and the vertical axis shows how many tasks have been finished within the same cycle time.
As you can see in this example, for the selected period this team has finished 13 tasks in 1 day, 7 tasks in 2 days, 11 tasks in 3 days and so on.
Looking at the range of delivery times in the example, you can see that once they initiate the work, this team can finish any work item (no matter what type or how complex it is), in less than 10 days, with an 85% probability of it happening. This is the power of probabilistic forecasting.
The Key Differences
The key difference between cycle time and lead time is the time between the commitment point and the point when your team initiates the work.
Another way you can think of it is: cycle time = lead time – period of not-yet-starting.
During the committed period and before the work has been pulled into the process, no work is happening yet. You’re in a parking lot. The difference (essentially) is the inactive period after you’ve committed to the work, but before you’ve actually started it.
So, if your business context entails selecting the next work item from your backlog at the moment your team has the capacity to take on new work, then your cycle time and your lead time become the same thing.
“Why do we have two different names, then?” I hear you ask. If that’s the case, you certainly don’t need the two of them. I’d just stick to cycle time.
If that’s not the case, it has to do with what the focus is on.
When we talk about lead time, the focus is on measuring and analyzing how long your client will have to wait for the deliverable once we’ve committed to delivering it.
When we talk about cycle time, the focus is on analyzing our internal performance, and the obstacles that could get in the way of delivering our results.
When your cycle time and lead time do overlap, you can think of them as two sides of the same coin.
How to Calculate Lead Time in Kanban
I hope that by now we all agree that lead time is calculated by a number of factors, not just your effort time.
When a work item enters your committed column, it will spend some time before your team gets started on it. Once it’s in progress, it will have to go through all the process steps.
Considering that your team works on more than one item at a time, your work item will have to wait until the team members responsible for each activity in the workflow have the capacity to start working on it.
Furthermore, your item’s waiting time will accrue as a result of any additional work that comes in between, along with any bottlenecks, external blockers, and any defects moving back and forth in the process.
Also, be sure to always include weekends and any other non-working time when you measure lead time.
Why? Because time is still, well, time.
If your project begins September 1st and ends September 30th, your client is waiting 30 days – not 21 days. (Always remember to think about it from their perspective!)
Remember the Cycle Time Histogram we introduced earlier?
What’s cool is that you can switch between cycle time and lead time, using the status filters on the right-side panel.
If lead time = cycle time + period of not-yet-starting, what this means is that the switch between both times is simply a matter of filtering out the time spent in your commitment column. Here is how to do it:
Tips for Improving Lead Time
The easiest and cheapest way to improve your lead time is to reduce the waiting time in your delivery workflow.
What this means is that, firstly, you have to start measuring your wait time and secondly, you should identify the obstacles in your process that slow you down.
Implementing a pull system is a great way to achieve this goal. Instead of pushing tasks into the process, teams pull work only when there is a demand for it, and they have the capacity to handle that demand.
Every process state has ‘In progress (IP)’ and ‘Done’ columns. For example, if a task passes ‘Code Review (IP)’, it moves to the ‘Code Review (Done)’ column.
‘Done’ columns are often referred to as queue states. These are passive since no one works on tasks in the queue states. Measure the time your work spends in your queue states. You can achieve tremendous improvement in your delivery speed just by reducing that time.
Adopting a pull system leads to reduced lead time which, in turn, means happier customers and greater profitability.
If you’re willing to explore the roadmap to build a delivery workflow where lead time continuously improves, I’d be thrilled to welcome you to our Sustainable Predictability program.
And let me tell you the truth, you won’t get there overnight. To achieve optimal delivery speed, you have to take control of your management practices. And the first step is to make sure that your board design enables that.
The structure of your board dictates how your team perceive their work. Following this structure, they will make choices, consciously and subconsciously.
Do you want to make sure you’ve built solid foundations? This week we’re giving away the first module of our signature program for free! It will be available for 7 days only so make sure you request your access now →
Follow the guidelines and implement the workbook. This approach will give clarity and direction. Remember, if you don’t know where you’re going, you’ll probably end up somewhere else.
Here is what I want you to remember from this article:
- Choose your commitment point and stick to it
- Don’t commit to a client’s request until you’ve gone through the process of narrowing down your options
- The difference between lead time and cycle time is the period of not-yet-starting
- Calculating lead time in Kanban involves multiple factors, not just effort time
- Don’t exclude weekends and non-working time – respect your client’s time spent waiting
I hope this article answered some questions you’ve had about lead time vs. cycle time. Thanks for hanging out with me. I’ll see you next week – same time, same place, as always. Bye for now!
