What is cycle time?
I’m not going to redefine the dictionary. There’s lots of documentation in manufacturing, for example, about what cycle time is. In the Kanban guide, we have a specific meaning for this. The Kanban guide is aimed at knowledge work when people are using their brain to get some work done, when we’re not creating widgets, for example, when each work item that comes in is a different type of a problem that involves different skills and so on.
Cycle time is where we’re measuring how long a work item takes to get from one part of our workflow to another part of our workflow.
The definition of workflow will have a started point and a finish point. You can have more than one started point and more than one finish point. For example, if you’re doing software, you could have a cycle time for development and testing. You could also have a cycle time for refinement, right sizing, through development, through testing, through goal life . Or you could have another one that goes even further that gets feedback from the customers.
So you could have any number of cycle times. A cycle time will have a starting point and a finish point and is about how long does it take? How long does the work item take to get from one point to the other. A lot of people ask me should we measure work time or work days, for example, or elapsed time?
It’s about elapsed time. There are a number of reasons for this. For example, if teams did actually work weekends, we hope they’re not working weekends, and you had some weeks where there was much more throughput and more work items were delivered that would be captured by doing it over a calendar of days, we would see how much work was done in calendar days. If you focus on work time, we have different public holidays and different parts of the world. Our cycle time for this, well we won’t include Diwali for example, or we won’t include Eid or we won’t include Christmas, or we won’t include summer holidays.
Oh, Daniela is gone on holidays. Oh, Alessandra’s gone on holidays. . And before you know, it, you’ve got eroding standards in terms of what cycle time means. And it’s just more simple to stick to calendar days. And it’s even more deep than that though, because if I start something today and I finish it today Cycle time is one.
It’s not zero. We round it up by one. So it’s the difference between the finish date and the start date if I’m using days. And I add one that runs it up to the cycle time, cycle time is how long does it take for a work item to get from a started point to a finished point over time, you will notice a pattern of how long different work items take.
And from that you can maybe plot cycle times on a cycle time, scatter plot. You can see over time different durations for how long work takes. And you can lift a ruler up that page and see where maybe 70% of the cycle times are done, or maybe even 85% of the cycle times are done. And from that, you can create a service level expectation.
You can say based on our history, 85% of items are done in 12 days or less. So our service level expectation is 12 days or less. It’s not a guarantee it’s based on an item that comes into our system that has been right sized. No elephants or mammoths coming to the system as long as the items are right sized.
We can get them done in 12 days or less. And once you have an SLE, you can improve your right sizing. Cause you can say instead of saying, is this an elephant or a mammoth? You can say does this feel like one of these items you can do in 12 days or less? Because if not, we need to break it down.
We need to make it smaller. So cycle time is how long does it take an item to get from a starter point to a finish point, you can have a number of starter points and a number of finish points you can even have a cycle time for an individual column on your workflow. That’s my nudge on cycle time.
Thank you.