Throughput

Story points measure a guess made at the start of the sprint. A proof from 1961 says which three numbers, measured from the work itself, would actually tell you if a team is getting faster.

August 25, 2026 7 min read

A team ships 34 points this sprint, 41 the sprint before that, 29 the one before that. The number moves every two weeks and nobody can say with a straight face whether the team is getting faster, slower, or just estimating differently, because a point measures how big someone guessed a task would be before it started, not anything that happened between start and done.

Three different numbers would actually answer the question, and none of them are points. The average number of things in progress at once, not a headcount taken this morning. How fast new things enter that same stretch of work. How long a thing spends in that stretch, start to finish. Most teams have a rough feel for all three and a precise, consistently defined measurement of none.

The proof that ties them together

In 1961, John D.C. Little published "A Proof for the Queuing Formula: L = λW" in Operations Research. The claim is almost suspiciously simple: for one consistently defined system, the average number of items in progress (L) equals the rate at which new items enter it (λ) multiplied by the average time each one spends inside it (W). What makes it worth a proof rather than an observation is how little it assumes about the mechanics: the order work gets done in, how variable task sizes are, how many people work in parallel, none of that matters. What it does assume is real: the 1961 proof requires the three means to be finite, the corresponding stochastic processes to be strictly stationary, and the arrival process specifically to be ergodic with a nonzero mean. Those are the paper's actual regularity conditions, not just another way of phrasing "steady state," and they're exactly what rules out a system where arrivals are permanently outrunning what gets finished. Given that, and given all three numbers measured against the same boundary, L = λW is not a rule of thumb. It is a proven identity.

An identity is a different kind of thing to build on than an estimate, not because it can't be manipulated (move where "started" or "done" gets marked, for example, and all three numbers move together), but because it's an internal consistency relation: under one fixed, honestly held definition of the boundary, L, λ, and W have to relate to each other exactly this way. A point estimate answers to nothing. These three numbers, measured consistently, answer to each other.

Why more agents doesn't mean more throughput

Here is where it matters to pick one boundary and hold it fixed. Say, ready-for-review to merged. λ is how fast items enter that boundary. W is the average time an item spends inside it. L is the average number of items inside it at once, a time-average over the same window λ and W are measured across, not a count taken at any single moment. Measured that consistently, the identity forces something whether a team notices or not: if λ goes up and W does not come down, L has to go up too, in whatever new steady state the system settles into. And if λ permanently outruns what the team can actually complete, there is no new steady state to settle into. The queue is unstable, L grows without bound, and calling that a new normal doesn't make it one.

Coding agents raise λ into that boundary sharply. A task that used to require scoping, writing, and testing before it was even ready to review now gets there in an afternoon. What they do not automatically shrink is W, the time a change actually spends between ready-for-review and merged, because that time is mostly review, coordination, and deciding what's actually right, the exact bottleneck we've written about before as an observation. Little's Law is why that observation isn't just an impression, as long as it's measured against the boundary the argument is actually about. If the rate entering review rises and the time inside review stays flat, the average number of items sitting in review has to rise too: more changes queued, more branches waiting, whether or not anyone is tracking it.

What measuring it actually means

This is what "measured rather than guessed" cashes out to. Not a better estimate of effort, and not a headcount taken once. Three numbers, all measured against the same boundary, all derived from timestamps that already exist: the average number of items in progress inside that boundary over the observation window, integrated from open and close times rather than counted at a single moment; the average entry rate over that same window, items divided by the window's duration, not a raw count; how long the ones that exited actually took from entry to exit. None of the three requires anyone to predict anything, and none of them is a snapshot.

Brief's Velocity Agent is built on the same principle: measuring from real activity instead of from an estimate made before the work started. It computes how fast a team is delivering from the work items themselves, so throughput is measured rather than guessed. Which specific numbers it computes to do that is its own implementation, not something this post is claiming to know. Little's Law is why "measured from real activity" is the right standard to hold any such tool to in the first place, not a description of one.

What the proof doesn't tell you

Little's Law says the three numbers move together. It does not say which one to fix, or why W is long in the first place. A long cycle time might be a genuine review bottleneck, an unclear requirement nobody resolved, or a decision the team never actually made and every reviewer is independently re-deriving. The law makes the tradeoff impossible to ignore. It does not make the diagnosis for you, and treating a rising L as self-explanatory is its own way of guessing instead of measuring.

If your team started shipping faster this quarter, is that completions going up, or work in progress quietly going up instead, counted as progress because it's moving, not because it's done?

Frequently asked questions

What is Little's Law? A proven identity from queueing theory, published by John D.C. Little in 1961: for one consistently defined system, the average number of items in progress equals the rate new items enter it multiplied by the average time each one spends inside it, L = λW. The 1961 proof requires the three means to be finite, the corresponding stochastic processes to be strictly stationary, and the arrival process to be ergodic with a nonzero mean: conditions that rule out a system where entries are permanently outrunning exits.

Why does adding AI coding agents to a team sometimes raise work in progress instead of throughput? Because the agents raise how fast changes enter review without necessarily shrinking how long each one takes to get through review. Applied consistently to that one boundary, ready-for-review to merged, Little's Law says if the entry rate rises and the time inside doesn't fall, the average number of items in review has to rise too, in whatever new steady state the system settles into, or grow without bound if entries permanently outrun what the team can complete.

How is measuring throughput with Little's Law different from tracking story points? Story points estimate effort before work starts and get totaled per sprint, a number that can drift for reasons that have nothing to do with speed, different estimators, different task breakdowns, deliberate inflation. Little's Law's three numbers, average work-in-progress, entry rate, and time-in-system, are derived from timestamps on the work itself rather than estimated, but they still depend on a team holding one honest, consistent definition of the boundary. Move that definition and the numbers move with it; the identity doesn't stop that, it just makes an inconsistent definition visible once someone checks whether the three actually relate the way the proof says they must.

What doesn't Little's Law tell you? Which number to fix, or why. It proves the three numbers move together; it doesn't diagnose whether a long cycle time comes from a genuine review bottleneck, an unresolved requirement, or a decision nobody actually made. That diagnosis is still a judgment call for a person to make, the law just makes it impossible to pretend the tradeoff isn't there.