In my last post, I talked about the basic metrics of flow (cycle time, throughput, and WIP) and shared what data you’d need to collect to get started. Now that you have the data — how do you turn it into meaningful flow metrics? You’ll just need to learn a few simple Kanban calculations. In this post, I’ll share how to calculate cycle time using start and finish times of work items.
How to Calculate Cycle Time
One of the simplest Kanban calculations to understand is how to calculate cycle time. A simple definition of cycle time is: The total amount of elapsed time between when an item starts and when an item finishes. An even better definition of cycle time is: The total amount of elapsed time that an item spends as Work in Progress (WIP) — but more on that in a later post.
Note the inclusion of the term “elapsed time” in both definitions. For cycle time, we don’t just track the amount of time someone actively worked on an item, nor do we arbitrarily bound the Kanban calculation by normal work time (e.g., by ignoring nights, weekends, and holidays — learn why here).
Remember, we calculate flow metrics from the customer’s perspective. What our customers care about is total elapsed time. With that definition, the Kanban calculation for cycle time is very straightforward:
Cycle Time = End Date – Start Date + 1
You might be wondering where the “+ 1” comes from in the above Kanban calculation; it’s to account for items that start and finish on the same day. Here’s an example: If you began work on December 15, and finished the work that same day, then 15 – 15 = 0. But you would never say an item had a cycle time of zero, would you? Certainly, your customer would never say that. Logically, that piece of work took one day to complete — not zero days.
But what about items that don’t start and finish on the same day? For example, let’s say an item started on January 1st and finished on January 2nd. The above calculation would give a cycle time of two days (2 – 1 + 1 = 2). This is a reasonable, realistic outcome, which makes sense from a customer’s perspective: If we communicate a cycle time of one day, then the customer might have an expectation that they will receive their item on the same day. If we tell them two days, they have a realistic expectation that they will receive their item on the next day, etc. This is just one way that Kanban calculations can help you communicate with your customers.
Cycle Time: Kanban Calculation Example
To illustrate the above Kanban calculation, let’s revisit the sample data that included in my previous post and let’s now add in the calculated cycle time:
| Work ItemID | Arrived | Departed | Cycle Time (days) |
| 1 | 01/01/2016 | 01/03/2016 | 3 |
| 2 | 02/02/2016 | 03/03/2016 | 31 |
| 3 | 01/02/2016 | 03/04/2016 | 63 |
If you do the above calculations yourself, you should come up with the same answers I did. I actually tried to do the math in my head first (never a good idea for me) and got the second and third answers wrong when I checked myself with Excel. I had forgotten that 2016 was a leap year!
You might be concerned that the above way to calculate cycle time is biased toward measuring cycle time in terms of days. In reality, you can substitute days with whatever notion of “time” is relevant for your context. Maybe that’s weeks, hours, or even sprints. (For a Scrum team, if you wanted to measure cycle time in terms of sprints, then the calculation would just be End Sprint – Start Sprint + 1.) The point here is that this Kanban calculation is wonderfully generic to fit all contexts.
Benefits of Measuring Cycle Time
The benefits of the Kanban calculation for cycle time cannot be overstated. Here are just a few reasons why learning how to calculate cycle time can be helpful for teams practicing Kanban:
- Cycle time is measured from the customer’s perspective, which gives you a common a language to talk about when an item will complete.
- It’s easy to get started learning how to calculate cycle time (you probably have all the data you need already).
- The cycle time calculation itself is very simple and straightforward and gives us a wealth of information about the overall performance of your process.
- Calculated cycle time allows us to make meaningful predictions about the completion times of individual items (I’ll explain that in depth in a later post).
That last point bears a little clarification. It’s all well and good to use cycle time to make predictions about the completion of individual items, but what if we want to make predictions about the completion of several work items? Specifically, what if we have 100 items in our backlog and we want to know when all 100 items will be completed? To answer that question we’ll need to use a completely different flow metric—the calculation of which will have to wait until next time. That metric’s name? Throughput.
As always, you can learn more about how to calculate cycle time and other Kanban calculations in my book, Actionable Agile Metrics for Predictability.
Thanks for reading!
Recommended Reading
To learn more about Kanban calculations, consult these resources:
