Velocity vs throughput: which to report when agents build
Stefan-Iulian Tesoi · · 5 min read
Throughput, counted in accepted items of a similar size. Velocity sums estimates, so it moves whenever estimating habits change, and adopting coding agents changes them. Throughput counts finished items and needs only that items are split to a consistent size, which agent-ready work already requires. Count acceptance, not merges, or rework inflates it.
The velocity vs throughput argument used to be a matter of taste between Scrum teams and Kanban teams. Once agents do most of the building, the two numbers start to disagree, and the disagreement says which one to trust.
Velocity vs throughput: what does each count?
Velocity is the sum of story points on the items a team finished in a sprint. Throughput is the count of items finished in a period. One adds up estimates; the other counts things.
| Velocity | Throughput | |
|---|---|---|
| What it counts | Story points on finished items | Finished items |
| Usual unit | Points per sprint | Items per week |
| Depends on | How the team estimates | How the team splits work |
| Moves when | The scale, the estimator or the habit changes | Item size or the finish line changes |
| Where it is defined | Team convention | The Kanban Guide's flow measures |
| How it gets gamed | Point inflation | Splitting too finely |
Neither is written into Scrum. The 2020 Scrum Guide mentions neither sprint velocity nor story points; it says only that "various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows." Throughput does have a formal definition. The Kanban Guide lists it among its required flow measures as "the number of work items finished per unit of time", and adds that it is "the exact count of work items."
Why does velocity drift once agents arrive?
Because velocity is made of estimates, and agents change who estimates, how carefully, and what a point means. The number drifts even when the amount of finished work does not.
Our own board shows it. Between weeks 39 and 41 of 2026, sprint velocity fell from 529 points to 499 while finished items rose from 131 to 180. Points per finished item went from 4.0 to 2.8 in a fortnight. Over the same weeks, items delivered by agents without a person attending rose from 51 to 169, and an item an agent files in Laimonade carries three points unless someone sets another estimate. A default pulls every average towards itself.
Points per item fell by almost a third in a fortnight. Either the work shrank or the estimating changed, and velocity cannot say which.
Three forces push the same way on any team adopting agents:
- Defaults replace judgement. Items filed by tools take whatever estimate the tool assigns.
- Effort stops varying. A point was a unit of effort, and effort is the term agents shrank. Whether story points still work with coding agents at all is a fair question.
- Fewer people estimate. Planning poker needs a room, and a team that no longer meets to size work stops calibrating against itself.
What makes throughput comparable week to week?
Items of a consistent size, and one finish line that does not move. Without those two, a count of items is as soft as a sum of points.
Right-sizing work items is the practice that provides the first. Every item has to fit under one agreed limit before it starts: small enough that one agent run builds it and one review sitting accepts it. That limit is also what makes an item executable at all, so splitting stories for coding agents does double duty here.
The checks that keep throughput in agile teams comparable:
- One size limit, applied before the item starts, not argued after it finishes.
- One finish line, accepted against the acceptance criteria.
- One rule for bugs, written down once.
- One unit of time. Weeks, if sprint lengths vary.
Our own figures carry the caveat that comes with this. If items were split smaller in weeks 40 and 41, then 180 overstates the gain. Throughput is only honest about the work when the size limit holds.
What counts as one item of throughput?
An item accepted against its acceptance criteria. A merged pull request is not one: a single item can take three pull requests, and a reverted change still counts as merged.
Count at acceptance and set reopenings against the week they happen. An item reopened within a fortnight is rework, and reporting it as a second finished item rewards the team for building it twice. When a coding agent is doing the building, the gap between merged and accepted is where most of the inflation hides, because merging is cheap and fast and acceptance is neither.
The count also needs a record of who did the accepting. In Laimonade, a coding agent cannot mark its own work done: it hands the item back with its evidence, and every closure records who or what made it. That record lets a team report accepted items and split them by who accepted them. Its management report carries velocity and finished items for each sprint, which is where the figures above come from.
Moving a team from one to the other
Report both for a quarter, then let velocity become a footnote. A switch made overnight loses the history that shows why the change was needed.
- Put velocity and throughput side by side, with the week agents arrived marked on the chart.
- Agree the size limit and the finish line before reading anything into the counts.
- Forecast from a range of past weeks, the slowest and the fastest of the last eight, rather than from an average.
- Keep story points as a signal for splitting, not as a forecast.
- Stop using either number as a target. The rest of the reporting stack sits in engineering metrics when agents do the building.
Frequently asked questions
Can you forecast with throughput alone?
Yes, for work that is already specified and right-sized. Sample past weekly throughput to build a range of completion dates, using eight to twelve weeks of history. What it cannot forecast is work nobody has written yet, so any date beyond the specified part of the backlog is a guess about specification, not delivery.
Does throughput reward splitting work too finely?
It can, which is why the size limit needs a floor as well as a ceiling. Every item must deliver something a reviewer can accept on its own. A split that produces pieces nobody can accept separately raises the count without adding anything, and a review that keeps rejecting fragments shows that quickly.
Should bugs count toward throughput?
Count them and report them separately. A bug fixed is work finished, and leaving it out understates what the team did. But a bug in an item accepted last week is rework on that item, not new output, and showing the two in one number hides exactly the signal a team adopting agents needs to see.