Throughput and velocity are both delivery metrics that Agile teams report every sprint, and they answer genuinely different questions dressed up in similar-sounding language.
"Throughput" is a simple count of completed items regardless of size; "velocity," specific to Agile teams, is a size-weighted point total per sprint. Conflating them misleads a stakeholder about whether "more got done" means more items or bigger items.
Item count versus point total
Both are valid delivery metrics, but they answer different questions. Throughput says how many items finished; velocity says how much estimated size finished, using a team's own point scale. Because point scales aren't standardized between teams, velocity should never be compared casually across teams the way a simple item count sometimes can be.
"We closed more tickets this sprint" (higher throughput), "but our velocity was actually flat because most of them were small."
"Velocity shouldn't be compared across teams the way throughput sometimes can be -- point scales aren't standardized between teams."
When a product manager asked whether "we completed more items this sprint" meant the team delivered more value, the team clarified that was a throughput gain, not necessarily a velocity or value gain.
Why the two numbers can tell opposite stories
The first example is the pattern to watch for: throughput can rise while velocity stays flat, because a team closed a lot of small items without moving much estimated size. Neither number is wrong -- they're just measuring different things, and a stakeholder who hears "we got more done" needs to know which of the two is actually being reported, since the practical implication is different in each case.
Want to learn "Throughput" in depth?
Lyra Practice teaches advanced non-native professionals the nuance of high-value expressions like this one, then has you practice using them in realistic work scenarios.
Start learning for free →The mistake
The mistake is treating item count and story-point totals as the same number, or casually comparing velocity across teams the way a throughput count might be compared. These are valid alternatives measuring genuinely different things, not one right metric and one wrong metric -- the error is only in blurring which one a given sentence is actually reporting.
Which one to reach for, and when
Throughput is the simpler, more transportable number: any stakeholder can understand "we closed 20 tickets," and it's fair to compare across sprints for the same team since item definitions tend to stay reasonably stable over time. Velocity is the more internally useful number for sprint planning, since it accounts for the fact that not all tickets take the same effort -- but it only means something within one team's own point scale, calibrated by that team's own history. Reaching for throughput when talking to an external stakeholder and velocity when planning next sprint's capacity is usually the right split.
Teams sometimes try to standardize point scales across squads specifically to make velocity comparable, but even then the comparison is fragile -- estimation habits drift, and two teams calibrated the same way at kickoff can drift apart within a few sprints. Throughput doesn't have this fragility problem, which is exactly why it stays the safer number for any comparison that crosses a team boundary, even an imperfect one.
Practice scenarios
Practice using throughput in situations like:
- clarifying whether "more got done" this sprint means more items or more points
- explaining why throughput rose while velocity stayed flat
- avoiding a cross-team velocity comparison that a throughput comparison could support
Useful practice phrases:
- "We closed more tickets this sprint -- higher throughput -- but velocity was..."
- "That's a throughput gain, not necessarily a velocity or value gain."
- "Velocity shouldn't be compared across teams the way throughput sometimes can be."
Throughput counts items. Velocity counts estimated size.
Know which one a sprint report is actually telling you before you draw a conclusion from it.
Lyra Practice helps advanced non-native English professionals learn the nuance of high-value workplace expressions and practice using them in realistic scenarios, so their English sounds natural, precise, and senior at work. Try Lyra Practice.