Cycle time is one of the most valuable metrics you can use to acquire a better understanding of your work process. It really helps you forecast your production process precisely. Those who are familiar with Lean and Agile know that there are two different ways to measure cycle time:
- Excluding non-working hours (plus weekends).
- Including non-working hours.
This is a controversial topic in many organizations practicing Lean and using Kanban software solutions or similar project management tools.
At Kanbanize, we recently found out that many of our users are interested in this topic and some of them feel confused when it comes to cycle time calculation.
So, let’s explore this topic further.
Cycle time analysis
In short, cycle time is the total elapsed time you need to move a task from the moment it enters the “in progress” stage to the moment it is considered as finished. Keep in mind that these metrics should always be shaped from the perspective of the customer.
When measuring the average cycle time of the tasks on your Kanban board, for example, remember that customers don’t care how long you are going to work on something. They only care how long it will take for something to be done. These two perspectives are completely different. Having it in mind will help you make your future predictions much more precise.
Now, let’s explore the two options.
Cycle time calculation without non-working hours
When a customer (internal or external to your organization) places an order, the only thing that matters to them is the total cycle time for delivering what has been promised.
Let’s imagine that you measure the average cycle time without non-working hours and weekends. Based on the historical data of your workflow, the predictions state that your average cycle time is 8 days.
If a customer makes an order, they would expect a deliverable in exactly 8 days. However, your cycle time is calculated only for working hours. This means that you will be able to deliver after 12 days because you don’t count weekends as well. From your perspective, the work will get done as planned, but from the customer’s perspective, you will be late. This kind of misconceptions may bring you a high rate of customer dissatisfaction.
Many companies do that in order to reduce their cycle time. But this cycle time reduction is inaccurate and brings confusion.
Cycle time calculation including non-working hours
On the other hand, if you measure the cycle time of your assignments by including non-working hours (including weekends), you will be able to meet or even exceed customers expectations.
For example, on Friday you promise a customer that something is going to be done in 5 days. This means that the customer will expect to receive what you promised no later than the following Wednesday. Respectively, you will meet the expectations because you calculate the average cycle time including Saturday and Sunday. Which brings us to another aspect – holidays.
If you tend to exclude non-working hours from your cycle time calculations, you also need to exclude national holidays. This may turn into a huge pain especially if you work with remote teams. Those teams may consist of people from different geographical locations. Which means that you may need to exclude the national holidays of various different countries from the average cycle time. Things can get really messy.
Keep in mind, when customers expect something to be done in 30 calendar days, they will not count what your business hours are, whether there are public holidays or if weekends are excluded.
As Daniel Vacanti (author of Actionable Agile Metrics for Predictability) says “The easiest thing to communicate is the overall elapsed time. Everybody understands that. And by the way that’s our customer cares about anyway.”
So, whatever workflow management tool you use, maybe it is not the best idea to exclude non-working hours when measuring your cycle time. After all, it may blur your predictions and make them inaccurate.