Little's Law for Software Teams, in Plain English

Introduction

Most arguments about how a team should work are arguments about preference. Somebody likes finishing one thing at a time, somebody else likes having options when they get blocked, and the discussion resolves according to who is more senior or more tired.

There is one claim in this area that is not a preference. It is a mathematical result from queueing theory, it was proved in 1961, and it holds for any stable system regardless of what anyone on the team believes about it. It is also the single most useful thing to understand about delivery, and it takes about ten minutes.

What Is Little's Law?

Little's Law states that for a stable system, the average time an item spends in the system equals the average number of items in the system divided by the average rate at which items arrive and depart. For a software team:

Average cycle time = Average work in progress / Average throughput

Three quantities, all of which you already measure or can measure this afternoon. Work in progress is a count of started-but-unfinished items. Throughput is items finished per week. Cycle time is the average time an item takes from start to finish.

A Worked Example

A five-person team. Right now there are twenty items in progress across the team, and over the last twelve weeks they have finished an average of five items per week.

Cycle time = 20 / 5 = 4 weeks.

Now check that against reality. If the team believes items take about a week and the arithmetic says four, one of two things is true: they are not counting all their WIP, or they are remembering the fast items and forgetting the slow ones. Both are extremely common, and the discrepancy is itself a finding.

Next, drop WIP to ten and change nothing else:

Cycle time = 10 / 5 = 2 weeks.

Same people, same skills, same working hours, same throughput. Half the delivery time. Nothing was optimised, nobody worked harder, and no tool was introduced. The team simply stopped starting things.

This is the entire argument for WIP limits, and it is why that argument does not depend on anyone's opinion about focus or multitasking.

The Objection, and the Honest Answer

The obvious objection: if we halve WIP, surely throughput halves too, so cycle time is unchanged and this is a trick.

It is a good objection and the answer is that throughput is not proportional to WIP beyond the point where people have one thing to work on. A developer with four open items does not produce four times the output of a developer with one. They produce slightly less than one developer's worth, because switching between four contexts costs real time and holding four contexts costs real attention. See context switching.

So reducing WIP from four per person to two per person leaves throughput roughly flat, or nudges it up. Reducing it from two to one probably does start to cost you throughput, because people genuinely do get blocked. That is precisely why the practical recommendation is two per person rather than one.

The law does not say less WIP is always better. It says cycle time is determined by WIP and throughput, and it tells you exactly where the trade sits.

The Three Assumptions

Little's Law is exact, but it is exact about averages over a period in which the system is stable. Three conditions must roughly hold, and teams violate all three routinely.

1. Arrivals roughly equal departures

Over the measurement window, the amount of work entering should roughly match the amount leaving. If the backlog is growing steadily, the system is not stable and the law will understate your cycle time. Check this first: it is the most commonly violated condition and the easiest to see on a cumulative flow diagram.

2. Items eventually leave

Every item that starts must finish or be explicitly removed. Teams that leave abandoned work in an in-progress state forever break this badly, and the broken version is worth noticing: those zombie items are counted in WIP, so they inflate cycle time in the arithmetic exactly as they inflate it in reality. Closing them is not gaming the metric, it is fixing the system.

3. Consistent units

Count the same things in WIP as in throughput. If throughput counts stories but WIP includes subtasks and bugs, the arithmetic is meaningless. This sounds obvious and is the most common practical error.

How to Use It

Do not put Little's Law on a dashboard. It is not a metric, it is a relationship, and a tile showing WIP divided by throughput adds nothing to the two tiles showing WIP and throughput.

Use it in three situations instead:

• As a sanity check. Compute the predicted cycle time and compare it to the measured one. A large gap means one of the three assumptions is broken, and finding out which is more informative than either number alone.
• As a forecast. Someone asks how long a new item will take. WIP divided by throughput gives you the honest average answer immediately, before the item is estimated or even understood. For the better probabilistic version, see Monte Carlo forecasting.
• As an argument. When somebody proposes taking on one more parallel project, this is the sentence that makes the cost concrete: everything currently in flight gets proportionally slower, and here is the multiplier.

What to Do This Week

Count your current WIP. Look up your average weekly throughput. Divide. Compare that number to what your team says delivery takes, and then to your actual measured cycle time.

If the three numbers disagree, you have learned something more valuable than any of them individually. Follow it up with WIP limits and throughput, and see the flow metrics guide for how the pieces connect.