Little's Law

Why does starting more work make everything take longer? Little's Law gives a precise answer. It describes a simple relationship between three quantities in any stable system: how many items are in it, how quickly items flow through it and how long each item stays. Knowing any two lets you work out the third. In software delivery, it means that if a team's throughput stays the same while its work in progress grows, the average time to finish each item must grow too. The same holds for portfolios of large initiatives, where starting too many efforts at once stretches every one of them. No amount of effort changes that arithmetic.

The law is named after John Little, an operations research professor at MIT who published the first formal proof in 1961. It applies to supermarket queues, call centers, factories and software teams alike. Kanban practitioners, notably Daniel Vacanti, popularized it in software as the mathematical basis for limiting work in progress. For delivery leaders, engineering managers and agile coaches, Little's Law turns the intuition that teams should finish before starting into a dependable rule.

Definition of Little's Law

Little's Law states that in a stable system, average work in progress (L) equals average throughput or arrival rate (λ) multiplied by average time in the system (W), often written L = λW. In delivery terms, average cycle time equals average work in progress divided by average throughput.

It links three core flow metrics and provides the reasoning behind WIP limits and shorter cycle time.

The Three Variables

Work in progress is the average number of items that have started but not finished. In a team, it is the number of cards between the start and done columns.

Throughput is the average number of items finished per unit of time, such as items per week. In a stable system, the rate at which work arrives roughly equals the rate at which it finishes, so throughput can stand in for the arrival rate in the formula.

Cycle time is the average time an item spends between starting and finishing. Rearranging the formula, it equals work in progress divided by throughput.

Conditions for the Law to Hold

The relationship holds exactly for long-run averages in a stable system, where the rate of items starting roughly equals the rate of items finishing.

Work started must eventually finish or be counted as removed, and the average age of work in progress should not be steadily rising.

When these conditions are not met, such as during a period of heavy intake, the law still points in the right direction but the numbers will not match exactly. The law also says nothing about the size of individual items, so a mix of very large and very small items can hide long waits for the large ones.

Importance of Little's Law in Delivery Management

Little's Law explains why limiting work in progress works. If throughput is fixed by the team's capacity, cutting work in progress is the most direct way to cut cycle time.

It provides a sanity check on plans. A team that finishes 5 items a week and has 40 in progress should expect an average cycle time of about 8 weeks, whatever the plan says.

It also shifts conversations from effort to system design. Faster delivery comes from changing how much is started, not from asking people to work harder. Because it is simple arithmetic, the law is easy to explain to executives and stakeholders who are not familiar with agile practices.

Little's Law and Financial Management

Every item in progress represents investment that is not yet returning value, so excess work in progress ties up capital in partly finished work.

Longer average time in the system raises the cost of delay for the value that work is meant to deliver.

The law shows that adding work without adding capacity lengthens delivery for everything, which should be weighed when approving new initiatives.

Reducing work in progress often speeds delivery without additional spending on people or tools.

Common Challenges

Teams sometimes apply the law to forecast individual items, but it describes averages, not the time any single item will take.

Unstable systems, such as teams with fast-growing backlogs of started work, break the conditions of the law and make calculations unreliable.

Inconsistent definitions of start and done can make work in progress and cycle time impossible to compare. Throughput can also fall as work in progress rises, because of context switching, which makes the effect of overloading a team even worse than the formula alone suggests.