Cycle Time

Definition
Cycle time is how long the actual work on a task takes once someone starts it, excluding any time it spent waiting in a queue first.

Why it matters

The gap between the two clocks is the real insight, not either number alone. A tiny cycle time next to a huge lead time says the problem is the queue, not the speed of the work. The fix differs. Asking people to work faster will not help when the real issue is capacity or priority, while clearing the backlog or routing work better will.

Cycle time also shows how much real capacity a process uses. That matters before taking on more customers or deciding what to automate. As a rough rule, the average amount of work in progress equals throughput multiplied by lead time, so a long queue and a slow flow tend to arrive together.

How to apply it

  • Measure from when work starts to when it finishes, never from when the request arrived.
  • Put it next to lead time for the same process to see how much of the wait is queue and how much is work.
  • If cycle time is small and lead time large, look at capacity and priorities, not at how the work is done.
  • Use it to estimate how many tasks a team can absorb before it needs more people.
  • Watch for it creeping up while lead time looks stable. That can mean a task is quietly getting harder.
  • Automate the steps with the longest cycle time first, where automation returns the most capacity.

What it is

Every request has two clocks. Lead time starts when the request arrives and ends when it is delivered, so it is what the customer feels. Cycle time starts only when someone begins the work and stops when it is done. The difference between them is waiting.

Take a support reply. A ticket arrives on Monday morning and is picked up on Wednesday. The reply takes ten minutes to write. Cycle time is ten minutes. Lead time is two days.

Common mistakes

  • Measuring from the date the request arrived, which gives lead time and hides where the delay sits.
  • Averaging across very different tasks. A five-minute task and a three-day task need their own figures.
  • Pushing people to shorten cycle time when the delay is in the queue.
  • Cutting cycle time by skipping checks, which moves the cost into rework.
  • Counting a task as started when it is assigned, not when work actually begins.
  • Reporting the figure once. A trend over several weeks shows what a single number cannot.
Worked example

Suppose a six-person support team at a software company. A ticket arrives on Monday, is picked up on Wednesday, and the reply takes ten minutes to write. Lead time is two days, and cycle time is ten minutes. The team tracks its work on a Trello board with lists for new, in progress and done, and records when each card moves into progress. Over one month the medians are 25 minutes of cycle time and 31 hours of lead time. The gap sits in the queue, not in the work, so hiring would not fix it. The team changes the routing so each ticket is assigned as it arrives, and median lead time drops to nine hours within six weeks, while cycle time stays almost the same.

Tools in the example

Some links are affiliate links: we may earn a commission at no cost to you. It never decides a ranking. How we work with partners

  1. Article

    Lead Time

    The customer's whole wait, of which cycle time is one part.

  2. Article

    Throughput

    How many items are finished in a given period.

  3. Article

    Bottleneck

    The step where work queues up.

  4. Article

    Capacity Planning

    Deciding how much work a team can take on.

  5. Article

    Value Stream

    The full chain of steps that cycle time is measured within.