Throughput shows up constantly in sprint retros and delivery reports, and it carries one extra discipline in this domain that general business use doesn't require.
In Agile, Scrum, and Kanban teams, throughput usually means the number of completed items -- tickets, stories, or changes -- finished over a sprint or period, counted simply regardless of size. It becomes misleading only when it's compared across teams or sprints without noting differences in item size.
The same rate concept, applied to work items
Software-delivery throughput is the same underlying rate concept as the general business sense, just applied to completed work items instead of, say, support tickets or warehouse orders. The premodifier pattern "team throughput" is standard here: it names the team as the system the rate is measured through, the same way "system throughput" or "line throughput" names a different kind of system elsewhere.
"Team throughput improved after we cut the approval steps -- we're completing more tickets per sprint."
"Before comparing our throughput to the other squad's, we flagged that their tickets tend to be much smaller, so a straight item-count comparison would be misleading."
"The engineering manager reported delivery throughput for the quarter as completed change requests per two-week cycle, broken out by team."
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 one domain-specific discipline: item-size qualification
The discipline to add on top of the general definition is item-size qualification. A raw completed-item count only means what it appears to mean when the items being counted are roughly comparable in size, which is exactly why comparing two teams' throughput numbers directly can be misleading. A team closing twenty small tickets and a team closing twenty large ones do not have equal throughput in any useful sense, even though the raw numbers match.
The domain-specific mistake, then, is comparing raw completed-item counts across teams or sprints with very different item sizes as if the numbers meant the same thing. Either qualify the comparison by noting item size, or switch to a size-weighted metric if that's genuinely what's being compared -- which is exactly the question the throughput-vs-velocity comparison below exists to sort out, since velocity is Agile's own size-weighted answer to this same problem.
Reading a throughput number in context
A single sprint's throughput number rarely means much on its own -- what matters more is the trend over several sprints, and whether that trend holds steady once ticket sizes and scope stay reasonably consistent. A sudden throughput spike is worth investigating rather than celebrating outright: it can reflect a genuine process improvement, or it can reflect a batch of unusually small tickets getting closed together, which would show up as a real number with no real underlying improvement behind it. The same caution applies in reverse to a sudden drop.
Practice scenarios
Practice using throughput in situations like:
- reporting sprint or delivery-cycle throughput in a retro
- flagging that a cross-team throughput comparison needs an item-size caveat
- distinguishing a raw completed-item count from a size-weighted metric
Useful practice phrases:
- "Team throughput improved after we..."
- "Before comparing our throughput to..., we should note that..."
- "We reported delivery throughput as completed items per..."
Team throughput is a completed-item count, not a completed-value score.
Qualify it for size before you compare it, and it stays a fair number instead of a misleading one.
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.