WIP Limits and Little's Law, Explained
After reading this you will be able to pick a work-in-progress limit that keeps your team busy without letting cards crawl, and to check your board's numbers against Little's Law by hand.
What the simulator shows
Picture a kanban board with three columns: backlog, in progress, and done. A team of developers pulls cards from backlog into in progress, works on them, and moves them to done. The rule that governs the middle column is a WIP limit: the maximum number of cards allowed in progress at once.
The tempting move is to raise that limit. If four cards in progress is good, surely eight is better, since nobody sits idle. The simulator shows why that intuition fails. Raise the limit and watch each card take longer to finish, while the number of cards reaching done per week barely moves. The board looks busy. The output does not grow.
Here is the hook. Suppose your team finishes 5 cards per week no matter what, because that is the real capacity. With 5 cards in progress, each card spends about a week in the middle column. Push 15 cards into progress and each one now spends about three weeks there. You did not ship faster. You just made every card wait behind fourteen others.
When to use this, and when not
Use the simulator when you run a flow of similar-sized work items through a shared team: a software backlog, a support queue, a content pipeline, a maintenance roster. It answers one question well: given your team size and how much multitasking hurts you, what WIP limit gives the shortest cycle time without starving anyone?
Do not use it to forecast a fixed-scope project with hard task dependencies. That is a critical-path problem, not a flow problem. If you need to know which tasks set the deadline, reach for the Critical Path (CPM/PERT) Calculator instead. If you already have real weekly throughput and want a delivery date with a confidence range, use the Monte Carlo Project Forecast.
The simulator assumes a stable system: work arrives and leaves at roughly matching rates over the window you measure. Little's Law is only exact for such a system. If your backlog is growing without bound, the averages below drift and the identity stops holding.
Little's Law: the identity behind the board
Little's Law relates three long-run averages of any stable queue.
Here L is the average number of items in the system (your average WIP), \lambda is the throughput (items completed per unit time, sometimes called the arrival rate in a stable system), and W is the average cycle time (how long one item spends in the system). The law is not a model with assumptions to tune. It is an accounting identity, true by the way the three quantities are defined.
Rearranged for cycle time it reads:
This is the whole lesson. If your throughput \lambda is fixed by real team capacity, then raising L (more cards in progress) raises W (cycle time) in exact proportion. Double the WIP and you double the wait. Nothing ships sooner.
Why throughput does not keep rising
You might object: surely more cards in progress means more gets done. Up to a point, yes. When the team has idle capacity, adding work raises throughput. Past the point where everyone is busy, throughput hits a ceiling set by the team, and extra WIP only adds waiting.
Worse, real teams pay a context-switching tax. Each extra concurrent task a person juggles costs overhead, commonly measured at 10 to 20 percent per extra task. So beyond a certain WIP, throughput does not just plateau. It falls. The simulator models this: with a switching cost of 15 percent, a developer working two cards at once delivers only 2 \times 0.85 = 1.7 cards' worth of effective effort, and three cards at once yields about 3 \times 0.70 = 2.1, so more juggling buys less and less.
Reproducing the demo with default settings
The demo runs a team of 4 developers, an average card size of 2 developer-days, a context-switching cost of 15 percent per extra concurrent card, and moderate size variability. Follow the numbers for three WIP limits.
- Raw capacity is 4 developers, and each card needs 2 developer-days, so with no switching tax the team could finish 4 / 2 = 2 cards per day, about
10per five-day week. - At a WIP limit of
4, each developer focuses on one card. No switching tax applies. Throughput \lambda \approx 10 cards per week. Average WIP L = 4. By the law, cycle time W = 4 / 10 = 0.4 weeks, about2days. - At a WIP limit of
8, each developer juggles two cards. Effective capacity per developer drops by15percent, so throughput falls to 10 \times 0.85 \approx 8.5 cards per week. Average WIP L = 8. Cycle time W = 8 / 8.5 \approx 0.94 weeks, about4.7days. - At a WIP limit of
12, each developer juggles three cards. Effective capacity drops to about70percent, throughput to 10 \times 0.70 = 7 per week. Average WIP L = 12. Cycle time W = 12 / 7 \approx 1.71 weeks, about8.6days.
Read the trend. Going from a limit of 4 to 12 tripled the WIP, cut throughput from 10 to 7, and stretched cycle time from about 2 days to nearly 9. That is the collapse the tool draws for you.
Reading the sweep chart
The one-click comparison sweeps the WIP limit from 1 to 12 and plots throughput and cycle time against it. Two shapes appear. Throughput rises steeply while the team has idle hands, then flattens once everyone is busy, then sags as the switching tax bites. Cycle time is flat and low while WIP is small, then climbs, and past the plateau climbs steeply.
The sweet spot is the WIP limit where throughput reaches its peak and cycle time has not yet started to climb. For this team of four, that is a limit near 4: throughput is at its top of about 10 per week and cycle time is still 2 days. This matches the rule of thumb that a good WIP limit sits close to the number of people.
Common mistakes
The first mistake is treating a high WIP limit as a productivity setting. It is a waiting-time setting. Fix throughput at 8 cards per week and every card you add to progress adds 1/8 of a week, about 0.6 days, of pure waiting to the average.
The second mistake is ignoring variability. When card sizes vary a lot, a loose WIP limit lets a few large cards clog the board and block small ones behind them. A tight limit protects the queue. In the simulator, turning variability up while the WIP limit stays at 8 can push average cycle time from about 4.7 days to well over 6, even though average throughput barely changes.
Do not set your WIP limit far above your team size to "give people options." A team of 4 with a limit of 12 in the worked example shipped fewer cards (7 per week versus 10) and made each one take four times as long. Busy is not the same as done.
The third mistake is measuring cycle time over an unstable window. If your backlog grew all quarter, your board was not stable, and Little's Law will not reconcile. Measure over a stretch where the queue length was roughly flat.
Related tools
Once you have picked a WIP limit and stabilized your board, your real weekly throughput becomes a forecasting input. Feed it to the Monte Carlo Project Forecast to turn "we finish 8 cards a week" into a dated, probabilistic completion range. If your work has strict ordering, model it with the Critical Path (CPM/PERT) Calculator. For fitting fixed-size items into fixed-capacity containers, a different packing problem, see the Box & Bin Packing Calculator. And when you are choosing between process options against several weighted goals, the Weighted Decision Matrix scores them and tests how fragile the winner is.
Frequently asked questions
What WIP limit should I set?
Start near the number of people who work the board, then tune. For a team of 4, try 4 to 6. The sweep chart in the tool shows exactly where your throughput peaks and your cycle time is still low. Run it with your own team size and switching cost.
Does Little's Law require any assumptions about arrival patterns?
No. It holds for any queue discipline and any arrival pattern, as long as the system is stable over the measurement window (items leave about as fast as they arrive). That is why it is called an identity, not a model.
Why does throughput fall instead of just flattening?
Because of the context-switching tax. Once each person juggles more than one card, every extra concurrent card costs 10 to 20 percent of effective effort. At 15 percent, three cards each give only about 0.70 of a card's worth of focus, so total output drops below the single-focus ceiling.
Can a WIP limit be too low?
Yes. If the limit is below the team size, people sit idle. A limit of 2 for a team of 4 in the example leaves two developers with nothing to pull, so throughput is only about 5 cards per week instead of 10. The floor is roughly the number of people.
How do I measure my real cycle time?
For each finished card, record the date it entered in progress and the date it reached done, and take the difference. Average those differences over a stable window. Then check: average WIP should equal your weekly throughput times that average cycle time in weeks.
Related tools
Box & Bin Packing Calculator
How many boxes, bins or trucks? First-fit-decreasing packing by capacity or 3D size.
Critical Path (CPM/PERT) Calculator
Which tasks actually set the deadline — schedule, slack and critical path from a task list.
Weighted Decision Matrix
Score your options against weighted criteria — with a sensitivity check on the winner.
Round-Robin Schedule Generator
Everyone plays everyone: fixtures by the circle method, byes included.
Seating Chart Optimizer
Assign guests to tables around keep-together and keep-apart rules.
Secret Santa Generator
Draw gift-exchange pairs with exclusions, no self-draws guaranteed.