cycle time

Does this title sound confusing? Don’t worry. By the end of this article you will see that it is simpler than you think. You will be able to measure the right cycle time with your eyes closed.

For those of you who are not so familiar with the term, cycle time is one of the most valuable metrics you can use to acquire a better understanding of your work process. It 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:

  1. Excluding non-working hours (plus weekends).
  2. 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.

How to Calculate Cycle Time

In short, cycle time is the total elapsed time you need to move a task from the moment it enters the “in progress” (working) stage to the moment it is considered as finished. So the simplest way to measure the cycle time of an assignment is to count the number of days it spent being worked on.

Well, most of the modern workflow management systems calculate the average cycle time automatically, but just to know the simplest formula is as follows:

Cycle Time = End Date – Start Date 

In other words, if you start a task on the 15th of April and complete it on the 25th of April, then the cycle time is 10 days.

For items that start and finish on the same day you can modify the formula to:

Cycle Time = End Date – Start Date + 1

However, most software solutions give you the opportunity to measure cycle time in different ways: excluding or including non-working hours. And here is the potential bone of contention.

cycle time definition

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.

1. 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.

2. 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.

After all, you decide how to calculate cycle time. However, 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 says “The easiest thing to communicate is the overall elapsed time. Everybody understands that. And by the way that’s what 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.

Try Kanbanize for free

Subscribe to our blog. Get each new piece of content straight into your mailbox.

Read insightful articles from top Agile/Lean thought leaders and our experienced team.