When a team feels slow, the instinct is to start more things, more tasks in flight, more irons in the fire, so more gets done. A century-old piece of math says that backfires. Starting more work makes a team finish work slower, and limiting work-in-progress is one of the simplest ways to speed up.
Key Takeaways
- Little's Law: average lead time equals work-in-progress divided by throughput (Little's Law).
- With throughput roughly fixed, more WIP means longer lead times, so everything takes longer to finish (Little's Law).
- High WIP creates traffic jams of development work, a core idea in Reinertsen's Principles of Product Development Flow (Little's Law and flow).
- Limiting WIP forces finishing over starting, and lead times drop.
The Law
Little's Law is a result from queueing theory, and for software it says something simple and unforgiving: the average time a piece of work takes to get through your system equals the amount of work-in-progress divided by your throughput (Little's Law). Lead time equals WIP divided by throughput. A team can only finish things at a certain rate, its throughput, and that rate is set by real constraints (people, review capacity, deploy pipeline), not by how many things you start. Double the number of tasks in flight without changing how fast you can finish them, and you don't finish twice as much. You double how long each thing takes to come out the other end.
Why Starting More Slows You Down
Picture a checkout line. Adding more shoppers doesn't make the cashier faster; it just makes everyone wait longer. Development works the same way. Every task you start but haven't finished sits in a queue, consuming attention, needing coordination, going stale, and blocking others. High WIP also multiplies context-switching, each person juggling five in-flight tasks pays the context-switching tax five times over. Reinertsen, in his work on product-development flow, describes the result as traffic jams of development work: a lot of things started, moving slowly, none of them done.
| More WIP | Less WIP |
|---|---|
| Everything in progress, nothing done | Fewer things, finished faster |
| Long lead times | Short lead times |
| Heavy context-switching | Focus |
| Work goes stale in queues | Work flows through |
A Concrete Version
A team of five has fifteen tasks in progress, three each, and everything is dragging; features sit "90% done" for weeks. They set a WIP limit: no more than six tasks in flight, and you finish something before starting the next. At first it feels wrong to leave capacity "idle." Within two sprints, features start closing fast, because the team now swarms to finish work instead of scattering to start it. Throughput didn't change; the same five people stopped clogging their own pipeline. That is Little's Law in action.
How to Apply It
The practice is limiting work-in-progress, the core of Kanban. Cap the number of items allowed in each stage, and when you hit the cap, the rule becomes "stop starting, start finishing" (Little's Law and Kanban). A blocked task gets unblocked before anyone picks up something new. This pairs with the small-batches logic behind frequent deploys: small units of work, finished and shipped, rather than many large ones half-done. It also connects to why 100% utilization backfires: a team jammed to capacity with in-flight work has no flow.
What This Means for Teams
Little's Law reframes a slow team. Before adding people, which Brooks's Law warns can make things slower, look at how much work is in flight; often the team isn't short on capacity, it's drowning in started-but-unfinished work. Limiting WIP is free and fast. When you do add senior capacity, the gain shows up as more throughput only if the team finishes work rather than starting more, a discipline experienced engineers tend to bring. See available engineers.
Frequently Asked Questions
What is Little's Law?
A queueing-theory result stating that average lead time equals work-in-progress divided by throughput. In software, it means the more things you have in progress at a fixed finishing rate, the longer each one takes.
Why do WIP limits make teams faster?
Because throughput is set by real constraints, not by how much you start. Limiting work-in-progress forces the team to finish before starting more, which cuts lead times and reduces context-switching.
Isn't leaving capacity idle wasteful?
It feels that way, but starting more work than you can finish just creates queues and long lead times. Finishing work fast beats starting lots of work slowly.
How do I set a WIP limit?
Cap the number of items allowed in progress (Kanban-style), and enforce "stop starting, start finishing" when you hit the cap. Tune the number until work flows without people sitting genuinely blocked.
The Bottom Line
Starting more work does not finish more work; Little's Law guarantees that with a fixed throughput, more work-in-progress just means longer lead times. Limit WIP, finish before you start, and a team that felt slow gets faster without adding a single person, because the pipeline stops jamming itself.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
