A team with 20 open PRs is mathematically slower than a team with 3.
Not “feels slower.” Not “probably slower.”
Is slower.
If your tickets take two weeks to cross the board while coding takes a few hours, the problem isn’t effort — it’s how much work your team keeps in flight at the same time.
And there’s a 65-year-old law that explains exactly why.
The equation
Little’s Law, proven by MIT professor John Little in 1961, applies to any stable flow system over a long enough interval.
Lead Time = WIP / Throughput
In plain English:
- Lead Time — how long it takes for a ticket to go from started → merged → deployed
- WIP — Work In Progress, the number of items currently in flight
- Throughput — how many items your team completes per unit time (usually per week)
This is not a metaphor. It governs factories, airport security lines, and fast-food drive-throughs.
It also governs your Git workflow — whether you acknowledge it or not.
The example that breaks the illusion
Let’s run the numbers on a real team.
Priya’s team closes 10 PRs per week on average (measured over the last 8 weeks). At any given moment, they have 20 PRs open (in progress + in review).
Their lead time is:
20 WIP / 10 PRs per week = 2 weeks
That means every ticket entering the system today is guaranteed to take about two weeks to ship — even if the code itself takes 3 hours.
When someone asks:
“Why does this take two weeks if coding takes half a day?”
This is the answer.
The code is not slow.
The developers are not slow.
The queue is long.
The part that actually changes how you work
If throughput is roughly stable (your team works at a certain pace), then:
Lowering WIP lowers lead time proportionally.
Same team:
- WIP 20 → 10 → lead time drops from 2 weeks to 1 week
- WIP 20 → 6 → lead time drops to ~3 days
Nothing else changes.
No overtime.
No process overhaul.
Just finishing work before starting new work.
This is why WIP limits exist in Kanban — not as a constraint on developers, but as a way to shorten delivery time by physics.
“If I limit WIP, people will sit idle”
This is the most common objection — and it’s backwards.
A team with 10 open PRs is slower than a team with 3.
Why?
Context switching is expensive
Every open branch is cognitive load. Ten branches means ten partial states competing for attention.Half-done work has zero value
A PR at 90% is still 0% delivered.Waiting PRs are inventory, not progress
In manufacturing, inventory is waste. In software, a PR sitting in review for days is exactly that.
Limiting WIP forces a simple rule:
Finish something before starting something new.
That alone compresses your delivery timeline.
You can measure this from Git (no fancy tools needed)
You don’t need Jira dashboards or expensive analytics. You can get all three variables directly from Git.
Throughput — PRs merged per week
gh pr list --state merged --limit 200 \
--json mergedAt \
--jq '[.[] | .mergedAt | fromdate | strftime("%Y-W%V")]
| group_by(.)
| map({week: .[0], count: length})'
Average the last 8 weeks for a stable number.
WIP — what’s currently in flight
# PRs in review
gh pr list --state open | wc -l
# Branches not yet merged (likely in progress)
git fetch --prune
git branch -r --no-merged origin/main | wc -l
Add both — that’s your WIP.
Lead time — created → merged
gh pr list --state merged --limit 50 \
--json number,createdAt,mergedAt \
--jq '.[] | {n: .number, hours: (((.mergedAt|fromdate) - (.createdAt|fromdate))/3600|floor)}'
Don’t just look at the average — look at the spread. A few PRs taking 10+ days can dominate the system.
What to do with the numbers
Once you have all three:
- If the equation matches your lead time → your system is stable. Lower WIP to go faster.
- If your lead time is longer → you have bottlenecks (reviews, CI, environments). Fix those first.
- If it’s shorter → you’re likely measuring WIP wrong or hiding variance.
If you’re leading a team and this number is higher than expected, you’re not alone — most teams never measure it.
A practical starting point for WIP limits
There’s no universal number, but these are solid defaults:
- In Progress ≈ team size
- In Review ≈ team size ÷ 2
Example (6 devs):
- In Progress = 6
- In Review = 3
From there, adjust slowly. Not weekly — quarterly. The signal takes time.
If lead time is too long:
Don’t add people — lower WIP.
When perception and math disagree
This is the uncomfortable part.
A team with:
- WIP = 20
- Throughput = 5/week
Has a 4-week lead time.
It doesn’t matter if individual PRs “feel fast.”
Users don’t feel individual PR speed.
They feel system lead time.
When the board says “we’re delivering” but the math says 4 weeks — the business experiences 4 weeks.
The takeaway
You don’t need a new process.
You don’t need better estimates.
You need a constraint:
Stop starting. Start finishing.
This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it’s actually used in real engineering teams.
Little’s Law looks simple — until you apply it and realize your entire workflow is shaped by it. In the book, I go deeper into how this connects to branching strategies, PR flows, and why some teams get faster as they scale while others slow down.
