Copied to Clipboard
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.