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.
Top comments (11)
WIP reduction works in a stable flow system. software teams often aren't - a 3-PR team can still have a week-long review cycle if the bottleneck is a single reviewer. fixing that beats WIP limits.
Spot on — and that's exactly where Little's Law stops being a prescription and starts being a diagnostic. The math still holds with a bottleneck; it just tells you your effective throughput is capped at whatever the constraint can process.
Lowering WIP pulls lead time down, but the floor is set by the slowest stage.
I usually pair it with Theory of Constraints for that reason: Little's Law surfaces whether you have a flow problem, ToC tells you where to fix it. A team with one overloaded reviewer doesn't really have a WIP problem — they have a review-capacity problem wearing a WIP costume. Capping WIP without touching the constraint shifts the queue from "in progress" to "waiting to start". Feels calmer, doesn't ship faster.
This is basically what Part II of Git for the Working Developer digs into — the structural decisions teams make around branching, ownership, review setup, and release flow, and how each of those can become a hidden bottleneck. Happy to share a sample if it sounds useful.
yeah but calling it "diagnostic" still feels generous - most teams can spot a review bottleneck without a formula. the hard part isn't identification, it's convincing 8 devs to stop pulling new tickets while the constraint is still active. law can't touch that part.
Fair — and you're naming the part most articles skip. Identification is the easy half; the political half is real, and no formula on its own crosses it.
Where I'd push back gently: the formula isn't only for identification, it's the artifact you use to do the convincing. "I'm busy" is eight individual stories; "we ship two-day features in three weeks" is one shared number. That shift from individual perception to shared metric is usually what unlocks the behavior change you're describing — and it's why I think PMs end up using Little's Law more effectively than engineers do. You already deal in that translation work every day.
that distinction lands - "we're overwhelmed" is a feeling, "arrival rate > departure rate" is something you can put in a slide. the formula earns its keep there.
"Stealing 'arrival rate > departure rate is something you can put in a slide' for the next time I need to convince a room — that phrase is the artifact."
ha - steal away. though I'd add a caveat: some rooms need the emotional version first. walking in cold with 'arrival rate > departure rate' can feel like a lecture. sometimes 'we're overwhelmed' is the door opener, then the formula is the proof. sequencing matters.
"Yeah, that lands. The formula's a confirmation move, not an opening one — leading with the number cold sounds like an audit. Once someone in the room says 'we're drowning,' the data stops being abstract and starts being theirs. Sequencing earned."
"confirmation move, not an opening one" is a cleaner frame than mine. that phrase probably gets more traction in the room too - it positions the data as validation rather than indictment.
The Little's Law framing is right and underused. The half that doesn't get written about often: WIP isn't just open PRs — it's open PRs plus in-flight design discussions, plus the half-investigated bug threads in slack, plus the "I'll get to it" tickets that were never moved out of the backlog mentally. Cycle-time math gets clean only when you count the invisible WIP. The intervention that actually moved the needle for our team wasn't a WIP cap, it was a weekly hour where everyone closes or formally re-parks any item they've been carrying for >5 days. The cap follows naturally once the carrying-cost of an open thread becomes visible.
You're completely right!!! Thank you for your comment!!!