There is one equation that explains traffic jams, hospital waiting times, slow software delivery, and why your team can never seem to finish anything. It's called Little's Law, and it's the most powerful mental model I've encountered in 30 years of working with teams.
Here it is:
Cycle Time = Work in Progress ÷ Throughput
That's it. Three variables. One equation. And it will change how you think about work forever.
The Three Variables
Work in Progress (WIP): The number of items currently being worked on. Not planned. Not estimated. Actually in progress right now. This includes everything — the feature being coded, the bug being investigated, the document being reviewed, the "quick thing" someone's doing on the side.
Throughput: The number of items completed per unit of time. Items per day. Features per week. Whatever unit makes sense for your context. The key word is "completed" — started doesn't count.
Cycle Time: The average time an item spends in the system from start to finish. From "we started working on this" to "it's done and delivered."
The Drive-Through Example
Imagine a fast-food drive-through. The kitchen can serve 10 cars per hour (throughput). If there are 5 cars in the queue (WIP), how long will each car wait on average?
Cycle Time = 5 cars ÷ 10 cars/hour = 0.5 hours = 30 minutes.
Now it's lunchtime. 20 cars are queued but the kitchen still serves 10 per hour.
Cycle Time = 20 ÷ 10 = 2 hours. The kitchen didn't slow down. The WIP increased. And cycle time quadrupled.
This is exactly what happens to software teams. Throughput doesn't change much week to week (it's constrained by team size, skills, and system complexity). But WIP can balloon without limit. And when it does, everything takes longer — not because people are working slower, but because items spend more time waiting.
The Software Team Example
A team completes 8 items per week (throughput). They have 24 items in progress. How long does each item take on average?
Cycle Time = 24 ÷ 8 = 3 weeks.
Management says: "That's too slow. We need items done in 1 week." They have two options:
- Option A: Triple throughput to 24/week. This means tripling the team size or magically making people 3x faster. Neither is realistic.
- Option B: Reduce WIP to 8 items. Same team, same speed. But items flow through in 1 week instead of 3.
Option B is free. It requires zero additional resources. It just requires the discipline to say "no" to starting new things until current things finish. That discipline — WIP limiting — is the practical application of Little's Law.
The Hospital Queue Example
A hospital emergency department treats 6 patients per hour. There are 30 patients waiting. Average wait time? 5 hours. Everyone knows this is unacceptable, but the typical response is "we need more doctors" (increase throughput). Sometimes that's necessary. But often the real leverage is in managing the inflow — triaging earlier, diverting non-emergencies, creating fast-track lanes for simple cases — which reduces WIP and cuts cycle time without adding resources.
Every queuing system follows the same physics. Little's Law is not a software concept — it's a universal truth about flow.
Exposing Impossible Commitments
This is where Little's Law becomes politically powerful. When someone asks you to commit to an impossible deadline, the equation makes it undeniable:
"You want 40 features delivered in 10 weeks. Our throughput is 3 features per week. That's 30 features in 10 weeks. To deliver 40, we either need to extend the timeline to 14 weeks, increase throughput (which means more people or less quality), or reduce scope to 30 features. Those are the only three options. The math doesn't negotiate."
This isn't being difficult. It's being honest. And it's the kind of honesty that prevents the slow-motion disaster of over-commitment, which is the root cause of most delivery failures.
Using Little's Law Every Day
Once you internalise this equation, you'll see it everywhere:
- In standup: "We have 12 items in progress and our throughput is 4 per week. That's a 3-week average cycle time. Can we finish some of these before starting new ones?"
- In planning: "We want a 1-week cycle time. Our throughput is 6/week. That means our WIP limit should be 6."
- In stakeholder meetings: "Adding 10 more items to the team's plate won't make things go faster. It'll make everything go slower."
- In retrospectives: "Our cycle time increased. Did WIP go up, throughput go down, or both?"
In our Mastering Kanban interactive lab, you experience Little's Law through simulation — running a drive-through with different WIP levels and watching cycle time respond exactly as the equation predicts. It's one thing to read about it. It's another to see it unfold with data you created.