Most engineering leaders can tell you how busy their squad is. Far fewer can tell you how much work their squad actually completes and ships in a given period. That gap is exactly what the throughput metric is designed to close. A throughput metric measures the number of work items a team delivers in a fixed time window, giving you a concrete signal about delivery capacity rather than just activity. Without it, sprint commitments become guesswork, capacity planning is fiction, and stakeholder trust erodes sprint after sprint. This page covers the definition, how to measure it, benchmarks, how to improve it, and how DevStats surfaces it automatically.
Key takeaways
- A throughput metric counts the number of tasks, stories, or pull requests a squad completes in a defined time window. It tells you whether your delivery pipeline is producing output consistently, and it is the foundation of any honest capacity conversation with stakeholders or product leadership.
- The formula is straightforward: Throughput = items completed / time period. A healthy squad of five to eight engineers typically completes between 20 and 40 issues per two-week sprint, though this varies significantly by team size, ticket granularity, and codebase complexity. No single number is universally "good" without context.
- The most common mistake teams make is confusing throughput with velocity. Velocity measures story points, which are subjective estimates. Throughput counts actual completed items, making it a more objective and harder-to-game signal of delivery health. Teams that optimize for velocity scores often miss what throughput reveals about real output.
- DevStats tracks your throughput metric automatically by connecting to your Git provider and issue tracker, surfacing trends against benchmarks from 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
Throughput metric definition
A throughput metric is the count of work items a software engineering team completes and delivers within a specific time period, typically a sprint, a week, or a month. It is a direct measure of delivery output: how much finished work actually exits the pipeline.
Technically, it is expressed as: Throughput = completed items / time period. The items counted can be pull requests merged, issues closed, or user stories accepted, depending on how your squad tracks work. You can see how DevStats surfaces this in the throughput feature, which aggregates completed items across your connected repositories and issue trackers. When throughput is stable and predictable, it becomes a reliable input for roadmap planning, hiring decisions, and release forecasting.
Why throughput metric matters for engineering teams
When squads do not track their throughput metric, sprint planning operates on intuition. Teams overcommit, underdeliver, and spend retros explaining why rather than improving how they work. Invisible bottlenecks accumulate in code review queues, waiting states, and blocked tickets, none of which show up in a burndown chart until it is too late. The consequence is not just a missed sprint: it is eroded credibility with product and business stakeholders who need reliable delivery signals to make investment decisions.
Throughput connects directly to the engineering leader's core KPIs. Predictable throughput enables accurate roadmap commitments. Declining throughput is often an early signal of squad burnout, scope creep, or process friction before those problems become retention issues. Teams that measure throughput consistently can also make honest tradeoffs between feature work and technical debt, because they have a baseline to reason from. If you want to see how your team's DORA metrics relate to throughput trends, the connection between delivery frequency and output volume is one of the clearest signals in software engineering measurement.
Within the SPACE framework, throughput sits in the Performance dimension: it measures outcomes, not activity. Measuring it is the first step. What you do with the data is where your judgment as an engineering leader comes in.
How to measure throughput metric
Throughput is calculated by counting the number of completed work items in a defined time window. The time window matters: use a consistent interval (weekly or per sprint) so you can compare periods meaningfully. Your data sources are your issue tracker (Jira, Linear, GitHub Issues) for story and task completions, and your Git provider (GitHub, GitLab, Bitbucket) for merged pull requests. You do not need a CI/CD pipeline to measure throughput, though combining it with deploy data gives you a fuller picture of how much completed work actually reaches production.
No universally published benchmark exists for engineering throughput in the way DORA benchmarks deployment frequency, because throughput varies too much by ticket size, team size, and work type. The table below describes qualitative performance levels based on patterns observed across engineering teams. You can compare your squad's numbers against peers using DevStats benchmarks, which are drawn from 1,000+ engineering teams.
| Performance level | Throughput benchmark | What it signals |
|---|---|---|
| Elite | Consistent, predictable output week over week with low variance | Stable process, well-sized tickets, minimal blockers |
| High | Mostly consistent output with occasional dips tied to identifiable events | Good flow with manageable disruptions |
| Medium | Noticeable variance sprint to sprint, output hard to predict | Process friction, inconsistent ticket sizing, or review bottlenecks |
| Low | Declining or erratic output over multiple periods | Systemic blockers, scope creep, or squad capacity issues requiring investigation |
Benchmarks vary by team size, codebase maturity, and release model. A squad of three will never match the raw output of a squad of twelve, but their per-player throughput rate is a more meaningful comparison point.
Throughput metric in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that two squads were consistently missing their sprint commitments despite reporting high activity. She pulled throughput data for the previous eight sprints and found that one squad was completing an average of 12 items per sprint while the other was completing 28, despite similar squad sizes and sprint goals. The lower-performing squad had a pattern: items were being opened, worked on, and then stalling in review for three to five days before closing. The bottleneck was not capacity. It was review latency.
She restructured the squad's daily standup to include a review queue check and set a team norm that no player should open new work while holding an active review request. Within two sprints, throughput for that squad climbed to 22 items. She tracked the change using issue cycle time alongside throughput to confirm that items were not just completing faster but were also spending less time in waiting states. The data surfaced the pattern. She made the call on what to change.
How to improve throughput metric
- Right-size your tickets before the sprint starts. Large, vague tickets inflate work-in-progress and reduce throughput. Audit your last three sprints: any ticket that took more than four days to close is a candidate for decomposition. Smaller, well-defined items move faster and give you a more accurate throughput signal.
- Reduce review wait time as a leading indicator. PR cycle time is one of the strongest leading indicators of throughput. When pull requests sit unreviewed for more than 24 hours, items pile up in progress and throughput drops. Set a squad norm for first-review response time and monitor it weekly.
- Limit work in progress per player. When players hold three or more active tickets simultaneously, context switching kills completion rates. Cap WIP at two items per player and watch how throughput stabilizes. DevStats's activity heatmap can show you where work is concentrated or spread too thin across the squad.
- Audit your sprint planning accuracy. Chronic over-commitment suppresses throughput scores artificially. Use planning accuracy data to calibrate how much work your squad can realistically complete in a sprint, then commit to that number rather than an aspirational one.
- Separate interruption work from planned work. Unplanned requests, bug escalations, and ad hoc meetings consume capacity without appearing in throughput counts. Track how much of your squad's time goes to unplanned work each sprint and create a buffer allocation for it rather than letting it silently erode planned throughput.
Throughput metric vs. velocity
Throughput and velocity are often used interchangeably, but they measure different things and have different reliability profiles. Throughput counts completed items objectively. Velocity sums story points, which are team-specific estimates that vary in meaning across squads and over time.
| Throughput metric | Velocity | |
|---|---|---|
| Measures | Count of completed work items | Sum of story points completed |
| Starts when | Work item is opened | Sprint begins |
| Ends when | Work item is closed or merged | Sprint ends |
| Best for | Cross-team comparison, capacity planning, flow analysis | Internal sprint-to-sprint trend within a single team |
Use throughput when you need an objective, comparable signal across squads or over time. Use velocity when your team has stable, consistent estimation practices and you are tracking internal sprint trends. The two metrics work well together when neither is used in isolation. You can explore how sprint data connects to throughput patterns in DevStats.