Throughput

Count completed items carefully

If a team completes 40 defined work items in four weeks, its average throughput is ten items per week. That calculation is simple. Deciding what qualifies as an item is the hard part.

One team may count pull requests. Another may count customer-facing changes, including several pull requests that together deliver one outcome. Neither number is wrong when its boundary is clear, but the two rates should not be compared directly.

A count does not describe importance

An illustrative maintenance patch and a new billing workflow can each count as one completed item. They may require very different effort and have very different effects on users.

Splitting work into smaller items can improve flow and make progress easier to see. It can also inflate a count if the team changes its decomposition style without changing the amount of useful work delivered.

Combine throughput with flow and quality

Use throughput with cycle time, work in progress, rework, and customer or service outcomes. A rising rate paired with a growing queue may indicate that work is being started faster than it is finished. A rising rate paired with more failed deployments may indicate instability.

Compare a team with its own relevant history, and record changes in the workflow. Throughput is most useful as evidence in a discussion about capacity and flow, not as a quota for individual developers.