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.
Interview question
What is the primary benefit of tracking a development team's throughput?
- a.To evaluate the efficiency and busyness of individual team members.
- b.To predict future delivery capacity and detect process bottlenecks.Correct
- c.To determine the total number of story points completed in a sprint.
- d.To establish a fair comparison of productivity across different teams.
Why? this is the answer
The card states throughput is "primarily for forecasting" and "excellent for spotting trends. A declining throughput is an early warning sign of a process problem, like a new bottleneck." It explicitly warns against using it to compare teams or as an individual performance metric.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles