Throughput metrics help you track how much work moves through software delivery over time. By counting what reaches a defined stage, such as merge or production, you can compare delivery across periods and investigate changes in the team's output. Understanding what each metric counts helps you decide whether a rising number reflects more completed work or simply a different way of dividing and tracking it.
The distinction starts with where the work finishes. Merged pull requests show what reached integration, while completed issues show what met the team's definition of done. Deployment frequency tells you how often changes reached production, so these counts answer different questions even when they appear on the same dashboard.
To interpret an increase, check the counting rule alongside delivery time and quality. Throughput contributes to that assessment, but cannot measure productivity on its own, which the SPACE framework treats as multidimensional.
Throughput metrics in software delivery
Throughput counts work items finished per unit of time, which means you need to agree on what an item is and where it starts and finishes. The Kanban Guide makes those definitions part of the workflow.
Throughput = completed work items ÷ time period
Suppose a hypothetical team completes 12 issues in two weeks, averaging six issues per week. That rate describes the period observed without promising the same result next week or showing how much customer value those issues created.
If your workflow ends at merge, merged PRs are a valid throughput metric. To measure delivery into production, though, you need to confirm that those changes reached production.
Some dashboards use “throughput metrics” more broadly. LinearB, for example, groups commits and reviews with opened PRs, merges and deployments, although its documentation distinguishes activity from output. Check the individual definitions before treating those measures as interchangeable.
Choosing throughput metrics
Use the table to match the metric to the decision you need to make. It applies the distinctions in Kanban, DORA and SPACE to common delivery events.
| Metric | What gets counted | Question it helps answer | What an increase cannot establish alone | Useful companion |
|---|---|---|---|---|
| PRs merged per period | PRs at the merge event, within the chosen repositories | How much work reaches integration? | That the changes reached production or delivered more value | Review time and evidence linking changes to deployment |
| Issues completed per period | Issues meeting a defined completion policy | How much tracked work reaches done? | That the work has the same size, type, or acceptance criteria as before | Issue type, cycle time, and reopened work |
| Deployments per period | Deployment events for an application or service | How often do changes reach production? | How many features shipped or whether delivery became more reliable | Change lead time, change fail rate, and deployment rework rate |
| PRs opened per period | PRs entering the tracked review workflow | How much new work is entering this stage? | That review or delivery kept pace | Merges, open PRs, and time spent waiting for review |
| Reviews completed per period | Review events under an explicit counting rule | How much review activity occurred? | That review quality improved or that more changes finished | Review duration, repeat review, and work reaching merge |
Opened PRs and completed reviews describe activity around the work, as do commits and lines changed. Use them to investigate a change in output, without treating activity quotas as a measure of productivity.
Keep different units separate. PRs, issues and deployments are different records, so you cannot assume a one-to-one relationship without a verified mapping. Adding their counts produces an unclear total, just as subtracting deployments from opened PRs does not calculate a delivery backlog.
How DORA uses the term throughput
DORA's current model uses five software delivery metrics, grouped into throughput and instability. Deployment frequency, change lead time and failed deployment recovery time measure throughput, while change fail rate and deployment rework rate measure instability.
More deployments per week means changes reach production more frequently. A rise in lead time or failed deployment recovery time means delivery or recovery takes longer, so an increase is not always an improvement.
When reading why DORA metrics changed, check whether the chart shows items per period or elapsed time. Keeping that unit visible avoids interpreting a longer wait as a higher delivery rate.
Measuring throughput consistently
Comparisons depend on a consistent definition of what finishes and which work is included. Kanban makes workflow definitions explicit, while DORA recommends measuring in the context of an application or service. Here is a way to put those principles into practice.
- Decide whether you need to measure work reaching merge or changes reaching production, then choose the corresponding finish point.
- Define the scope by specifying repositories, application, issue types, or team. For issues, include the status and acceptance policy that mean completed, so canceled items do not silently enter the delivery count.
- Choose the completion timestamp and counting rule, including how to handle duplicate events and repeated completions. If you count each issue only once, track reopenings separately to keep rework visible.
- Use equivalent time windows or show the denominator when calculating a rate. A weekly average does not tell you how many items finished in each week.
- Note changes in team composition, repository coverage, work types, item size and completion policy so you can account for them when comparing counts.
For observed throughput, count completion events directly. Substituting WIP divided by cycle time can hide assumptions about the system and the periods compared, making the result harder to check.
You can still change the workflow. If the finish point moves from “development complete” to “accepted,” mark when that happened so readers can distinguish a new definition from a change in performance.
Interpreting an increase in throughput
A higher completion rate means more items finished per unit of time, provided the definition and coverage stayed the same. To understand whether delivery improved, you still need to look at the work behind the count, as these hypothetical examples show.
A team splits large changes into smaller PRs, and the merge count rises. DORA recommends smaller batches to support fast, stable delivery, so this may be a useful change in practice. To assess it, check review time and quality, then confirm what reached production. The count alone cannot tell you how much of the increase came from splitting work, and smaller PRs are not evidence of manipulation.
A team that closes more issues while spending more time fixing bugs has finished more tracked items, but it may not have delivered more features. Break down the count by work type and check why the mix changed. Bug fixes could reflect old backlog cleanup or new problems, and the total cannot distinguish between them.
If an application is deployed more often while a larger proportion of its deployments respond to production incidents, the share of corrective work is also growing. Read frequency alongside change fail rate and deployment rework rate for that application before judging the increase.
Use complementary agile metrics to decide where to investigate, then check the underlying work before assigning a cause to the trend.
Flat throughput can still mean improvement if a comparable volume finishes sooner or with fewer failures. Even then, customer value requires evidence beyond completion or deployment counts, consistent with SPACE's view of productivity as multidimensional.
Choose a metric you can act on
Before using a throughput chart in a delivery review, make sure the team knows what was counted and over which period. Keep a relevant time measure and quality signal beside it.
When the count changes, use the definition to decide what to check next. More merged PRs calls for checking what reached production, while more completed issues calls for checking whether the work type or completion policy changed.