What is Cycle Time?
Cycle Time is a metric that measures how long it takes for an item to move from the “in-progress” column to the “done” column. It helps teams to determine jobs’ start and finishing times, as well as their general delivery capability. A process’ Cycle Time is calculated by dividing all the work-in-progress items by their average completion rate.
Why is Cycle Time important?
One of the most common questions stakeholders ask is “how long will this take?”. And it’s an important one - it helps them to determine costs, and to best plan for their market. But having to answer the question often leads to frustration from the delivery teams, who’d often answer “it will take as long as it takes”. Such a response does not allow clients to plan anything, and it shows a lack of efficiency on the delivery team’s side. The bottom line is: if delivery teams do not know how to provide this answer, customers will go to suppliers, who can.
Cycle Time is not only important to clients but suppliers as well. It is a great indicator of how well their business is doing. If a team’s Cycle Time varies - that information alone indicates underlying problems within the workflow or with the team competency itself.
How to calculate Cycle Time?
The way a team member would measure Cycle Time on a physical board is by writing the start date and time of when an item moves from the “backlog” to “in progress”. The Cycle Time only measures once an item starts to be worked on. After the item has traveled the length of the board, the team member would record the date and time of when the item reached the “done” column.
To learn what the Cycle Time was for a given item, you’d use this calculation:
The additional value of “1” corrects a potential “0-day” Cycle Time of those items that were completed on the same day that work on them got started on.
Calculating your process’ average Cycle Time
Knowing an individual item’s Cycle Time after the fact isn’t of that much help in and of itself. The value in making this measurement is in using it to predict the average Cycle Time for your process.
Teams that have been using Kanban in their operations for a while, can forecast the Cycle Time by dividing the total work in progress number by the average completion rate. For example, if there are 10 items in progress, and - on average - it takes 2 weeks for the team to complete an item, then the Cycle Time would be 5 weeks.
What does Cycle Time depend on? How to reduce it?
Looking at the above calculation we can see that the larger the count of “in progress” items is, the longer the Cycle Time will be. This is one of the reasons why Kanban seeks to limit WIP - it’s the quickest way to decreasing Cycle Time.
Another way to do this is to - of course - speed up working, and a great help with that is ridding the process of bottlenecks and blockers, helping items to journey across the board quicker.
Advanced Practices to Improve the Cycle Time
Classifying items on the board into groups - classes of service - can further help to decrease the Cycle Time. It relates to the variation in different types of work’ Cycle Times. Coding a new software feature will typically have a different Cycle Time to the fixing of a minor bug in it. Classifying items on your Kanban board will help you to best estimate delivery times and come up with the best mixture of items for production for the day, week, or Sprint.
Because Cycle Time is a measurement of time for a task moving from point A to point B, a team using Kanban could have separate Cycle Times for various process steps, e.g. ready, coding, testing. Unless explicitly stated, Cycle Time is usually the time between the “in-progress” column and the “done” column, at the furthest end of the board.
The power of digital Kanban boards is in their automatic, accurate, and easy tracking of all Cycle Times valid for your process, as well as of various other statistics.
Visualization is a key component of Kanban - it provides an easy way to grasp the Cycle Time of a process, also on the Cumulative Flow Diagram. The CFD shows the stability and predictability of work, additionally letting the team calculate and report on Cycle Times, not only on the overall speed of processing work.
We can see that in October, there were 20 customer requests (“to do”, blue area - letter A). Between October and November, the team was working on 20 requirements specifications (red area - letter B). Around the end of November, nearly 20 items had been completed regarding the requirements specification phase, and 20 items were being reviewed (green area - letter C). And at the beginning of December, the team had 20 items completed (turquoise area - letter D). So, their total Cycle Time for 20 items is about 2 months.
What are the key benefits of measuring Cycle Times?
- Having solid data on which process completion can be reliably predicted
- Gaining a stakeholder/customer viewpoint on your process - making communication easier and more meaningful
- Having constant access to your process’ speed and health, making you aware of any issues as and when they are happening.