← Back to glossary

Throughput

The rate at which a team completes work items—typically measured as features or bugs shipped per unit time. It's the ultimate measure of delivery effectiveness.

What is Throughput?

Throughput is how much work your team finishes and ships: 5 features per month, 20 bugs per week, 100 support tickets per day. It’s the output side of the equation—not how fast you work, but how much you actually deliver to customers.

Throughput differs from velocity: velocity measures points in a sprint (a forecast), throughput measures completed work (reality). A team might forecast 40 points per sprint but only ship 25 features per month—the variance signals gap between estimation and reality.

Measuring Throughput

Effective throughput counts something meaningful: shipped features, not lines of code. Not all features are equal (search feature ≠ button redesign), so you might weight them by complexity or impact. Some teams count defects fixed, support tickets resolved, or customers onboarded.

The key is consistency: count the same thing every period, measure trends, not individual weeks. One team ships 8 features one month and 4 the next—the variance might reflect vacation, technical debt, or priority shift. Trends over 3-6 months reveal true capacity.

Throughput vs. Velocity

Velocity is a team’s self-assessed capacity (points per sprint). Throughput is what actually ships. Gaps signal problems: estimates are wrong (too optimistic), definitions of done are loose (shipping incomplete work), or external blockers prevent shipping (waiting on other teams, infrastructure issues).

A healthy pattern: velocity and throughput roughly align. If velocity is 40 points/sprint but throughput is 4 features/month, something’s wrong. Either the points are too optimistic, or features aren’t shipping despite being “done.”

Cycle Time and Throughput

Cycle time is how long one item takes to ship (start to finish). Throughput is how many items ship per period. They’re related: if cycle time decreases, throughput increases (assuming the same work difficulty). If you reduce cycle time from 4 weeks to 2 weeks, you can ship twice as much in a quarter.

Little’s Law formalizes this: Throughput = Work-in-Progress / Cycle Time. If you have 5 items in progress and each takes 2 weeks, you’ll complete ~2.5 per week. To increase throughput, reduce cycle time or reduce WIP (or both).

Why It Matters for Product People

Throughput is the ultimate measure of team effectiveness. It’s not how hard people work or how many meetings they attend—it’s what ships. High-throughput teams deliver more customer value, faster iteration, and competitive agility.

Use throughput to identify team health and constraints. Declining throughput despite stable team size signals problems: increasing defects (causing rework), growing technical debt, or organizational friction. Address it before it cascades.

Also use throughput for capacity planning. If your team ships 12 features per quarter and you need 20 features, you need more team capacity, not exhortation. Math doesn’t lie.

Throughput connects to cycle time and WIP (Little’s Law), velocity and estimation accuracy, and team capacity planning. It also relates to product roadmap feasibility—roadmap commitments should be based on historical throughput, not wishful thinking.