Cycle Time, Work-in-Progress Limits, and Little's Law in Delivery Queues

A delivery queue exists wherever work waits before someone starts it. Tickets in a backlog, changes awaiting review, container images awaiting a vulnerability scan, migrations awaiting a deploy window: each is an arrival stream into a service system with a finite number of servers. The quantities that matter are countable without instrumentation beyond a task tracker, namely how many items arrive per unit time, how many are in flight at a given moment, and how long an item takes from arrival to completion.

Treating delivery as a queue is not a metaphor chosen for rhetorical effect. It imposes one identity that constrains any schedule and one nonlinear penalty for running close to full capacity. Both follow from arithmetic, not from opinion about process.

The conservation identity behind cycle time

Little’s law relates three averages. For a system in steady state, the mean number of items inside equals the arrival rate multiplied by the mean time each item spends inside:

L = lambda · W

The result carries no distributional assumptions. Arrivals can be Poisson or perfectly regular, service times exponential or fixed, priority order arbitrary, the number of servers anything from one upward. The only requirements are that the system is in steady state, that the boundary of “inside” is fixed, and that items do not appear or disappear except by arrival and departure. Little proved the result for general systems in 1961, and it is a conservation law in the same sense as mass balance.

The practical consequence is that the three quantities are not independent, so any two determine the third. A team receiving twelve items a week with thirty in flight completes them in two and a half weeks on average, whatever the skill of the people involved. If a commitment requires one week at the same arrival rate, the system may hold at most twelve items. That inference is arithmetic, and it holds before any discussion of effort, seniority, or tooling begins.

arrival_rate = 12.0   # items completed (and so consumed) per week
wip = 30.0
cycle_time_weeks = wip / arrival_rate          # 2.5 weeks

target_weeks = 1.0
max_wip = arrival_rate * target_weeks          # 12 items in flight, at most

The identity is exact only for averages over a window, and the window has to be long enough to average away weekly noise. It also applies strictly to a closed system, so the definition of “inside” matters more than the formula. An item parked in someone’s personal queue, in a refinement backlog, or blocked on an external vendor counts if the work is in progress and does not count if the request has not been accepted. Disagreements about whether a team is fast are often disagreements about where the boundary sits, and the boundary should be stated once and applied to both the count and the timings.

Waiting and working are different costs

Total cycle time decomposes into queueing time before work starts and service time while it runs, plus any rework after a check fails. Service time is bounded by the work itself: a change to a configuration parser takes what it takes. Waiting time is set by contention, and it is the part that varies by an order of magnitude with load.

The distinction matters because the two respond to different interventions. Reducing batch size, that is splitting large items into smaller ones, attacks service time and also reduces the variance of service time, which shortens queues downstream. Adding people attacks capacity. Neither addresses a queue caused by a downstream stage that is starved of attention, and neither helps if items wait for a decision rather than for hands.

A second distinction is between nominal and effective capacity. A stage with four engineers does not have four servers if one of them also answers support pages, or if all four must agree before a merge. Effective capacity is the number of items that can be actively advanced at once, and it is usually smaller than the headcount. Counting servers as people inflates every subsequent calculation.

The nonlinear penalty of high utilization

Queueing theory makes the nonlinearity explicit. For a single-stage system with utilization rho, mean service time E[S], and squared coefficients of variation of interarrival and service times c_a² and c_s², Kingman’s approximation gives the mean wait in queue:

def kingman_wait(rho, mean_service_s, ca2=1.0, cs2=1.0):
    # Approximate mean queueing delay for a G/G/1 stage.
    # ca2, cs2: squared coefficients of variation of interarrival and service time.
    return (rho / (1.0 - rho)) * ((ca2 + cs2) / 2.0) * mean_service_s

The factor rho/(1 − rho) is the whole story. At half load it is 1. At 0.8 it is 4. At 0.9 it is 9. At 0.95 it is 19, and at 0.99 it is 99. Waiting time inflates without bound as utilization approaches one, and the inflation is not gradual: the last five points of utilization cost more than the first ninety.

Utilization	Wait multiplier rho/(1 − rho)
0.50	1
0.80	4
0.90	9
0.95	19
0.99	99

This yields the central trade-off of any delivery system. Idle capacity costs money directly, since people are paid whether or not an item is ready for them. Queueing costs money indirectly, through delayed feedback, work that goes stale, and items that must be re-examined because the code around them moved. Which side of the trade a system should sit on depends on the relative cost of delay, and there is no universal optimum. What the formula rules out is the belief that high utilization is free. It is never free, and its cost grows faster than linearly.

Variability is the second lever. The factor (c_a² + c_s²)/2 is 1 when both streams are Poisson and 0 when both are deterministic. Halving the variability of arrivals halves the queue at fixed utilization, which is why smoothing intake, that is refusing to start everything at once, is as effective as adding capacity.

Sizing a limit from a target cycle time

A work-in-progress limit is a cap on how many items may occupy a stage at once. Sizing it starts from the identity and then accounts for the stage’s own capacity.

The steps are mechanical. Choose the stage where the queue actually forms, not the stage where the problem is noticed. Measure the completion rate over a window long enough to include normal variation, at least four to six weeks for weekly cadence. Decide the cycle time the stage must sustain. Multiply to get the maximum item count. Then compare that number with the count of people who can advance an item simultaneously: a limit below that count starves the stage, and a limit equal to it leaves no buffer for the wait that variability introduces, so the limit typically sits a little above the parallel capacity and well below the arrival backlog.

A limit is a policy, not a measurement. When a limit is reached, the correct response is to finish something before starting something, and the failure mode of every such policy is that the limit is silently exceeded for a “small” item. The count must therefore be enforced at the point where work is pulled, and the pull must be a real event rather than an intention.

Where the identity stops being useful

Little’s law describes averages, and averages conceal exactly what schedules are judged on. A five-item system with a two-week mean cycle time can hold one item for eight weeks while four finish quickly. Delivery commitments are about the tail, so the useful statistics are the 85th and 95th percentiles of completion, which the identity cannot supply; deriving those requires sampling from observed history, as covered in forecasting completion from throughput.

Three further limits are worth stating plainly. First, the identity assumes a stable system, and during a backlog reduction or a hiring ramp the averages are computed over a moving target. Second, a limit at one stage relocates inventory rather than removing it: capping review pushes items into the queue before review, and the total in flight is unchanged. Only a limit at the constraint, or a limit on the whole system, reduces total work in progress. Third, items blocked on an external dependency consume a slot without producing completions, which lowers measured throughput and lengthens measured cycle time for reasons no internal change will fix. Blocked work should be counted separately, because including it in the limit hides the blockage behind an apparently full queue.

The same arithmetic reappears wherever work converges on a shared resource. A critical path is the longest chain of dependent work rather than the busiest queue, and the two constraints interact: shortening the critical path moves the date, while shortening a queue that is not on the path does not.