A team completes 42 story points in one sprint, then 27 in the next. Has performance dropped? Not necessarily. The work may have contained more integration, production fixes or intentionally smaller backlog items. This is the central problem in story points vs throughput: both metrics can support better delivery decisions, but only when leaders understand what each one actually measures - and what it does not.
For software and IT teams working under genuine delivery pressure, the goal is not to declare a universal winner. The goal is to build a measurement system that improves forecasting, exposes workflow constraints and protects teams from being judged by misleading numbers.
What story points measure
Story points are a relative estimate of effort, complexity, uncertainty and, in some teams, risk. A five-point item should represent more delivery challenge than a two-point item, but it is not a promise that the item will take two and a half times as long.
Their value appears before work starts. During backlog refinement, points help a delivery team discuss scope, reveal unknowns and decide whether a backlog item is small enough to enter a sprint. A team that estimates consistently can use historical velocity - the number of completed points per sprint - as one input to sprint planning.
This makes story points useful where work is varied and the team needs a shared language for relative sizing. They are particularly effective for Scrum teams with a stable membership, a well-maintained Product Backlog and a clear Definition of Done.
The limitation is equally important: story points are local. One team's eight points cannot be reliably compared with another team's eight points. Point scales are social agreements, not standard units of productivity. The moment an organisation treats points as a cross-team performance target, estimation quality starts to deteriorate. Teams learn quickly that larger estimates create more apparent capacity, and the metric ceases to be trustworthy.
What throughput measures
Throughput is the number of work items finished during a defined period. For example, a Kanban team may complete 18 backlog items each week, while a Scrum team may complete 35 items per sprint. Unlike story points, it records completed work rather than an estimate made before delivery.
That makes throughput a powerful flow metric. Combined with cycle time, work in progress and item age, it helps teams understand how work moves through their system. It also supports probabilistic forecasting: if a team has historically completed between 15 and 22 similarly sized items per week, leaders can model likely completion dates instead of presenting a single, overconfident deadline.
Throughput is most reliable when work items are reasonably consistent in size. This does not mean every item must be identical. It means a team needs sensible slicing discipline. If one item represents a two-hour configuration change and another represents a six-week platform migration, a raw count of completed items says very little about delivery capacity.
Story points vs throughput: the operational difference
The practical distinction is simple. Story points describe the team's view of the work before it is done. Throughput describes the volume of work completed after it is done.
| Question | Story points | Throughput |
| --- | --- | --- |
| Primary purpose | Relative sizing and sprint planning | Flow analysis and delivery forecasting |
| Timing | Before delivery | After delivery |
| Best unit of analysis | One stable team | One workflow with consistent item types |
| Main risk | Comparing teams or gaming velocity | Counting badly sliced, uneven work items |
| Useful companion metric | Sprint Goal success | Cycle time and work in progress |
Neither measure proves value delivered. A team can complete a high number of points or items while solving low-priority problems. Product outcomes, customer impact, quality and reliability must remain visible alongside delivery metrics.
When story points are the better choice
Use story points when the immediate problem is planning a sprint with uncertain, uneven work. They create a structured conversation between Product Owner, engineers, testers and delivery leads. That conversation often matters more than the final number.
They are also useful when a team is learning to split work. If most items are estimated at eight or thirteen points, the backlog is probably too coarse for dependable sprint execution. A pattern of small, independently testable items creates a more controllable sprint and reduces the chance that work remains almost done at the end of the iteration.
Do not force points into every workflow. A support team handling incidents, service requests and operational changes may gain little from detailed estimation. The cost of estimating can exceed its planning benefit, especially where request arrival is unpredictable.
When throughput is the better choice
Use throughput when the priority is improving flow, managing demand or forecasting from actual delivery data. It is especially effective for Kanban systems, platform teams, DevOps functions and mixed portfolios where work arrives continuously rather than in neat sprint-sized batches.
Throughput also makes workflow problems difficult to hide. If completion falls while work in progress rises, the team may have too much work started, an approval bottleneck, constrained test capacity or an overloaded specialist. Velocity alone rarely identifies that constraint.
For forecasting, avoid using a simple average as if it were a commitment. A team that completed 10, 14, 17 and 23 items over four comparable periods has meaningful variation. Report a range and confidence level instead. This is more useful to stakeholders than a precise date built on unstable assumptions.
The failure modes leaders need to prevent
The most damaging mistake is turning either metric into a target. “Increase velocity by 20 per cent” encourages point inflation. “Complete more tickets” encourages teams to split trivial work, avoid difficult items or prioritise quantity over quality. Metrics should guide improvement, not become a scorecard for individual performance.
A second failure is mixing incompatible work. Feature development, defects, discovery, technical debt and incidents do not always have the same service characteristics. Separate work types where necessary, or at least make their composition visible. A sudden throughput change may reflect an incident-heavy week rather than a change in team capability.
Third, do not measure incomplete work as delivered. Story points only count when the item meets the Definition of Done. Throughput only counts when the item exits the workflow according to an explicit completion policy. Without disciplined quality standards, both measures reward activity rather than finished, usable outcomes.
A practical measurement model for delivery teams
For most organisations, the answer is not story points or throughput. It is a deliberate combination, used at the correct level.
At team level, use story points where they improve refinement and sprint planning. Keep estimates lightweight and avoid converting them into hours. Track velocity only as a planning signal for that team, not as a management comparison.
At workflow level, track throughput, cycle time, work in progress and ageing work. These metrics reveal whether the system is stable enough to make promises. They also create better conversations about bottlenecks than a sprint chart alone.
At leadership level, report forecast ranges, delivery confidence, material dependencies, quality indicators and outcome measures. Executives need to know whether an initiative is likely to land, what may delay it and whether it is producing the intended benefit. They do not need a league table of teams ranked by points.
A useful operating rhythm is to review flow data weekly, inspect sprint delivery at the end of each iteration and review forecasting assumptions whenever scope, capacity or demand changes materially. The cadence matters because metrics without a decision process become administrative overhead.
How to choose without creating metric overload
Start with the delivery decision that is currently weak. If teams struggle to select a realistic sprint scope, improve backlog refinement and relative estimation. If work is ageing in progress and deadlines are repeatedly missed, focus on flow metrics before adding another estimation ceremony.
Then define the rules. Specify which item types count, what “done” means, how blocked work is recorded and how often data will be reviewed. Jira configuration should support these policies rather than create reporting theatre. Clean workflow states and consistent issue hygiene are prerequisites for credible throughput data.
Finally, test whether the metric changes behaviour in the right direction. Better metrics should lead to smaller work items, fewer blocked items, more honest forecasts and stronger delivery conversations. If a measure produces defensive reporting or encourages teams to optimise a number, redesign the measure.
The strongest teams do not argue about which metric is fashionable. They use story points to make sensible choices before work begins, throughput to learn from what the system actually delivers, and quality standards to ensure that finished means genuinely finished. That is the discipline that turns Agile metrics from reporting noise into an operational advantage.