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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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."
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!!!