Throughput: Measuring What Gets Done
Throughput measures how many work items a team *finishes* in a time period, not how busy they are. It's used for forecasting future work and spotting bottlenecks. The footgun: never compare throughput between different teams, as item sizes and context vary.
WHY IT EXISTS: Teams need a reliable way to measure their delivery rate to make forecasts and improve their process. Metrics like story points can be gamed, and lines of code is meaningless. Throughput focuses on the only thing that matters to the customer: finished, valuable work.
THE MENTAL MODEL: Think of a factory assembly line. Throughput isn't how fast the machines are running or how busy the workers look (effort). It's the number of finished cars that roll off the line each day (completed items). It is a direct measure of output, not activity.
HOW IT WORKS: You count the number of work items (user stories, bugs, tasks) that a team moves to their 'Done' state within a specific timebox, like a one-week or two-week sprint. For example, if a team completes 8, 10, and 9 stories in three consecutive two-week sprints, their average throughput is 9 stories per sprint. This historical data becomes the basis for future planning.
WHEN TO USE IT: Throughput is primarily for forecasting. If a team's average throughput is 8 items per sprint, you can reliably predict they'll complete about 8 items in the next one. It's also excellent for spotting trends. A declining throughput is an early warning sign of a process problem, like a new bottleneck, team friction, or excessive work-in-progress.
WHEN NOT TO USE IT: Never use throughput to compare teams or as a performance metric for individuals. This creates perverse incentives, like splitting stories into artificially small pieces just to inflate the count. It's also less useful for teams whose work is highly variable and unpredictable, as their historical average won't be a good predictor of the future.
ONE CANONICAL EXAMPLE: A Scrum team is planning their next sprint. They look at their last four sprints and see they completed 7, 9, 8, and 8 user stories, respectively. Their historical average throughput is 8 stories per sprint. Based on this, the team can confidently pull 8 stories into the next sprint, knowing it's a realistic goal based on demonstrated past performance, not wishful thinking.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.