Engineering Throughput Explained: Measuring Delivery Without Gaming It
Throughput — how much work a team completes per sprint — is the simplest delivery measure and one of the most useful for planning. Used well, it anchors capacity. Used badly, it becomes a ticket-count leaderboard.
Sprint 20
60 → 56gap 4
Sprint 21
65 → 57gap 8
Sprint 22
72 → 58gap 14
Sprint 23
78 → 59gap 19
- Committed ↑ +18
- Completed → +3
Throughput is what the team demonstrably completes — the anchor a commitment should be checked against.
How this is calculated: Commitment rising, throughput flat in the methodology
What throughput is
Throughput is the amount of work completed in a period — usually a sprint — counted in issues or story points. Unlike velocity, it does not require estimates: counting completed issues works for any team, and is often steadier because it is immune to estimation drift.
Throughput counts everything completed in the period, including work added mid-sprint and work carried in from earlier sprints. That is what makes it a good capacity signal: it is what the delivery system actually produced.
Why it matters
Throughput is the most direct evidence of a team’s delivery capacity. Planning against it — rather than against headcount or hopes — produces commitments that the team has actually demonstrated it can meet.
Its variation matters as much as its level. A team whose throughput ranges from 40 to 55 should plan differently from one that ranges from 20 to 80.
Throughput also connects the other flow metrics. By Little’s Law, average cycle time is roughly work in progress divided by throughput. If throughput is flat and work in progress grows, each item takes longer to finish — which shows up as aging work and, at sprint close, as carryover. Watching throughput next to WIP is often the earliest warning that a sprint plan is too large.
How to calculate throughput
Expected carryover ≈ commitment − demonstrated throughput = 78 − 58 (median of 56, 57, 58, 59) ≈ 20 issues
Throughput (sprint) = issues (or points) resolved inside the sprint window
Planning anchor = median throughput over the last 6–10 closed sprints
Upper typical = 75th percentile (P75)Use the Resolved date to place work in a sprint. Exclude the in-progress sprint from history. Report unestimated issues separately when using points.
Median vs average
| Sprint throughput (points) | Mean | Median |
|---|---|---|
| 51, 13, 119, 48, 44, 52 | 54.5 | 49.5 |
The 119-point sprint shipped a release backlog; the 13-point sprint was a release freeze. The median ignores both extremes; the mean is pulled up by the backlog sprint.
Issues or points?
Counting issues needs no estimates and is surprisingly stable when a team keeps items reasonably small. Points add information when item sizes vary widely, but they drift over time as estimation habits change. Many teams track both: if points throughput rises while issue throughput stays flat, items are getting larger (or estimates are inflating), not delivery faster. Whichever unit you plan in, compare a proposal only with history in the same unit.
How to interpret throughput
- Flat throughput under rising commitment: the constraint is elsewhere (review, QA, release, dependencies). More planned work will not change it.
- Falling throughput: check bottlenecks, unplanned work and growing WIP first.
- Spiky throughput: often a batching release process; work completes in bursts when it ships.
- Issues vs points disagree: item size is changing — for example many small support tasks replacing features.
Always read throughput together with what the team was asked to do. Throughput that holds steady while commitment and carryover climb is not a delivery problem; it is evidence that the plan has outgrown the system. Conversely, a dip in throughput during a sprint dominated by incident response says more about operational load than about the roadmap.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes
- Ranking people by throughput. Closing tickets is not the same as contributing; reviewers and unblockers look “slow”.
- Setting throughput targets. Teams split tickets to hit them.
- Comparing teams. Issue size and definitions differ.
- Planning to the maximum. Use the median and the P75.
- Ignoring what the throughput was. Delivering lots of unplanned work is different from delivering the roadmap.
Leadership implications and questions to ask
Throughput should anchor planning and expose constraints — not evaluate people. When leaders see flat throughput alongside growing demand, the productive response is to find the constraint and reduce intake, not to push harder.
Questions engineering managers should ask
- Is our commitment in line with median throughput?
- What share of throughput is planned roadmap work versus unplanned, support or maintenance?
- Is a bottleneck — review, QA, release — capping throughput?
- Would issue counts be a steadier planning unit than points for us?
Example
Throughput was 48, 44 and 52 points in the last three sprints while commitment rose from 59 to 89. Bottleneck analysis showed QA was flagged in two of those sprints. Rather than adding more planned work, the team moved QA earlier in the sprint and capped new commitment at the median. Throughput held; carryover fell.
Related metrics and how the Capacity & Commitment report helps
See it on your own data in the Capacity & commitment report.
Related: cycle time, engineering bottlenecks, team capacity vs velocity and software delivery metrics.
The Capacity & Commitment report reports previous-sprint, 3- and 6-sprint average, median and P75 throughput in points or issues, and shows completed work next to what each sprint committed.
Frequently asked questions
- Is throughput the same as velocity?
- Velocity is throughput measured in story points. Throughput can also be counted in issues, which needs no estimates.
- Should throughput include carried-over work?
- Yes. Throughput counts everything completed in the period, wherever it started. Commitment accuracy is the measure that looks at the original plan.
Related guides
Engineering capacity planning
A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.
Capacity vs velocity
Team capacity and velocity are often confused. Learn what each measures, why velocity is not a productivity score, how carryover distorts velocity, and how to combine them for realistic sprint commitments.
Cycle time
What cycle time is, how it differs from lead time, how to calculate median and percentiles from Jira, why averages mislead, and why a CSV export alone cannot give you time per stage.
Software delivery metrics
A leader's guide to software delivery metrics: flow metrics, sprint predictability and DORA, what each can and cannot tell you, and how to avoid turning metrics into targets.