If you remember only one equation from process improvement, make it this one:
Lead Time = WIP ÷ Throughput
Or equivalently: WIP = Throughput × Lead Time
This is Little's Law, named after John Little who proved it in 1961. It's not an approximation. It's not a rule of thumb. It's a mathematical relationship that holds for any stable system — manufacturing lines, hospital ERs, software development teams, call centers, anywhere work flows through a process.
What It Means in Plain English
Lead Time is how long something takes from start to finish. The time a patient spends in the ER. The days from order received to order shipped. The weeks from feature request to deployment.
WIP (Work in Progress) is how much stuff is in the system at any moment. Patients currently in the ER. Orders being processed. Features in development.
Throughput is how fast stuff exits the system. Patients discharged per hour. Orders shipped per day. Features deployed per week.
Little's Law says these three things are locked together. You can't change one without affecting the others.
Why This Changes Everything
Most process improvement efforts focus on the wrong variable.
"We need to go faster." So teams try to increase throughput — add capacity, work overtime, push harder. But if you increase throughput without reducing WIP, Little's Law says lead time stays the same. You're just processing more stuff slowly.
"We need to reduce lead time." So teams attack individual step times, optimize handoffs, eliminate waste. All good. But the fastest way to cut lead time? Reduce WIP. It's not intuitive, but it's mathematically guaranteed.
The WIP Lever
Here's the counterintuitive insight: limiting work in progress is often more powerful than adding capacity.
Say you have 50 items in your system and throughput of 10 per day. Little's Law says lead time = 50 ÷ 10 = 5 days.
Option A: Double your throughput (expensive, hard). Lead time = 50 ÷ 20 = 2.5 days.
Option B: Cut WIP in half (free, immediate). Lead time = 25 ÷ 10 = 2.5 days.
Same result. One requires hiring and equipment. The other requires saying "not yet" to new work until current work is done.
This is why kanban boards have WIP limits. This is why "stop starting, start finishing" is a mantra in agile. This is why "multitasking" destroys productivity — it inflates WIP without increasing throughput.
Where People Go Wrong
Ignoring the "stable system" requirement. Little's Law assumes arrivals roughly equal departures over time. If you're drowning in ever-growing backlogs, you have a capacity problem that WIP limits can't fix. But WIP limits will make the capacity problem visible faster.
Measuring the wrong WIP. Count everything in your system, not just the stuff actively being worked. That feature "on hold" still consumes mental overhead, coordination effort, and context-switch cost.
Forgetting throughput has an upper bound. You can't reduce WIP to zero and expect infinite speed. At some point, you're starving the process. The goal is finding the WIP level that balances flow and utilization.
Applying It
Next time someone asks "why does everything take so long?", don't jump to heroic measures. Ask two questions:
- How much work is currently in progress?
- What's our actual throughput rate?
Do the math. Compare to what you actually observe. If lead time is higher than WIP ÷ Throughput, you have hidden WIP (queues, waiting, work that isn't tracked). If it matches, you know exactly which lever to pull.
Little's Law doesn't tell you how to improve. But it tells you the only three variables that matter — and which one is usually the cheapest to change.