⚙️ Cycle Time Calculator

How to Use the Cycle Time Calculator

Enter current work-in-progress (units started but not finished) and daily throughput (units completed per day), then press Calculate. You get cycle time in days, plus the WIP cap or throughput needed to hit your target. Count WIP honestly across every queue, not just the active stations.

Throughput should be the demonstrated completion rate, not capacity: use last month completions divided by working days. Targets go in the optional field; the calculator works backward to the WIP limit or throughput rate that achieves it. One honest measurement beats ten estimates.

The Formula (Little Law)

Little Law states that average WIP equals average throughput times average cycle time, for any stable system. Rearranged, it gives cycle time directly. It is accounting, not theory: units pile up exactly as fast as the completion rate drains them, so the average wait is forced by the ratio.

Worked Example

A shop holds 100 units in process and completes 20 per day: cycle time = 5 days. Target 3 days: either cut WIP to 60 (20 × 3) or raise throughput to 33.3 per day (100 ÷ 3). Cutting WIP is usually cheaper than adding capacity, which is why lean programs start with WIP limits, not faster machines.

Why WIP Is the Villain

Every unit waiting is time added to everything behind it. High WIP hides problems (defects discovered weeks late), inflates lead times, and ties up cash. Little Law makes the mechanism exact: double the WIP at constant throughput and cycle time doubles, no exceptions, no management required.

The counterintuitive fix: start fewer jobs. Teams fear idleness, so they keep everyone "busy" starting work, which queues it everywhere and slows everything. Limiting WIP feels slower at each station and is dramatically faster end to end. Flow efficiency beats resource efficiency.

Bottlenecks and Throughput

Throughput is set by the slowest step, the bottleneck. Improving anything else just moves the queue. Find the bottleneck by looking for the biggest pile of waiting work in front of a station; that pile is the system telling you where it hurts. Strengthen that step (more capacity, less downtime, better quality) and throughput rises.

Quality at the bottleneck deserves obsession: every defect there wastes the scarcest resource. Inspect before the bottleneck, not after, so it never works on doomed units. An hour lost at the bottleneck is an hour lost for the whole system; an hour saved elsewhere is an illusion.

Cycle Time vs. Lead Time vs. Takt

Three times, three jobs. Cycle time: how long work takes once started. Lead time: how long the customer waits from order to receipt (cycle time plus queues before start, plus delivery). Takt time: how fast you must produce to meet demand (available time ÷ demand).

The health check: cycle time should sit comfortably under takt time, with lead time as close to cycle time as order handling allows. Gaps between the three name your problems: long order queues, slow starts, or plain insufficient capacity.

Beyond Manufacturing

Little Law is universal. Software teams: tickets in progress ÷ tickets shipped per week = cycle time in weeks; WIP limits are kanban 101. Hospitals: patients in beds ÷ discharges per day = length of stay. Restaurants: parties waiting ÷ seating rate = wait time. Anywhere work queues, the law rules.

The same calculator serves all of them; only the units change. That universality is why operations managers reach for it first: one equation diagnoses factories, clinics, and code shops alike. Measure WIP, measure throughput, and the truth appears.

Common Cycle Time Traps

Vanity throughput: counting started units instead of finished ones inflates the number and hides queues. Measure completions, the only throughput that matters. Batch-and-queue thinking: processing in giant batches feels efficient at each station while starving the next; smaller batches flow faster overall.

Ignoring variation: averages lie when arrivals spike; a system fine on average drowns on Mondays. Track the 90th percentile cycle time, not just the mean, because customers remember the worst experience. Buffer capacity, not hope, absorbs variation.

Getting Started Tomorrow

Walk the floor and count everything started but unfinished: that is your WIP. Pull last month completions for throughput. Plug both into the calculator. The resulting cycle time, shown to the team without blame, starts more improvement conversations than any consultant speech.

Then pick one bottleneck and one WIP limit as experiments. Measure for two weeks. Little Law guarantees the direction of change; your job is only to hold the experiment steady long enough to see it. Operations improvement is mostly applied arithmetic plus courage.

A Second Worked Example: The Support Ticket Queue

Little's Law works anywhere work piles up, including a support desk. Say your team receives 40 tickets per day and on average 10 tickets are open and being worked at any moment. Cycle time equals WIP divided by throughput: 10 divided by 40 is 0.25 days. In an 8-hour workday, that is 2 hours per ticket on average, from the moment a ticket opens to the moment it closes.

Now the team hires and throughput rises to 50 tickets per day, but WIP creeps up to 15 because agents start more tickets than they finish. The new cycle time is 15 divided by 50, which is 0.3 days, or 2.4 hours. Throughput went up 25 percent, yet tickets got slower, because WIP grew faster than throughput. This is the classic trap: adding capacity without controlling WIP often makes the queue worse before it makes it better. Cap WIP first, then add people.

The Units Trap: Keeping Arrivals, WIP, and Time Aligned

Little's Law is simple division, but the units must match or the answer is nonsense. If throughput is measured per day and WIP is a simple count, cycle time comes out in days. If throughput is per week, cycle time comes out in weeks. Mixing them, say dividing a WIP count by a per-hour rate while expecting days, silently produces garbage.

Calendar time versus working time is the subtler trap. A team that completes 25 orders per working day with 50 in WIP has a cycle time of 2 working days, but if weekends are idle, the customer experiences closer to 3 calendar days. Decide up front which one you are measuring. For customer promises, use calendar time. For process improvement, use working time. Write the choice down wherever the number gets reported, because someone will eventually compare the two and conclude the math is broken.

Two Levers, Very Different Effort: Cutting WIP vs Raising Throughput

The formula gives you two levers: lower the WIP or raise the throughput. Cutting WIP in half cuts cycle time in half with no new hires, no new equipment, and no process redesign. It costs discipline, finishing work before starting new work, and nothing else. That is why experienced managers attack WIP first.

Raising throughput is the expensive lever. It means faster machines, more staff, or redesigned steps, and every one of those takes money and months. Worse, extra throughput with uncontrolled WIP just builds a bigger pile faster. The sequence that works: cap WIP, watch cycle time fall, and only then invest in throughput if demand still exceeds what the calmer system can handle. Most teams find the WIP cap alone buys them a year of breathing room.

Measuring Cycle Time Without Fancy Tools

You do not need special software to get a trustworthy number. For two weeks, stamp every job with a start date when work actually begins and an end date when it is truly done, not shipped to the next queue. At the end, average the elapsed times. Thirty samples is enough to see the shape; a hundred is plenty for decisions.

Count WIP the honest way: work that has started but is not finished, including items waiting on someone else. Teams routinely undercount WIP by ignoring the "waiting" pile, which is exactly the pile Little's Law cares about. Then compute throughput as items finished per day over the same period. If the measured cycle time roughly matches WIP divided by throughput, your data is sound. If the two disagree wildly, the WIP count is usually the lie, go find the hidden queues.