What is throughput and how does it differ from velocity?

Tests whether you know throughput is count-based and velocity estimate-based. Define throughput as items finished per sprint regardless of size, contrast velocity's point sum, pick throughput for forecasting and keep velocity for calibration.
What's really being asked
This question tests whether you understand the difference between estimate-driven and flow-driven planning. Velocity is a Scrum artifact based on story points, while throughput is a flow metric from the Kanban Guide for Scrum Teams. The interviewer wants to see if you know that velocity measures estimated effort completed and throughput measures actual items finished, and more importantly whether you can choose the right metric for forecasting, diagnostics, and cross-team communication.
The full answer
First, define throughput as the count of items completed per unit of time, typically per sprint or week, where a three-point story and an eight-point story both count as one. Second, define velocity as the sum of story points completed in a sprint. Third, contrast them by noting that velocity depends on estimation accuracy and team-specific point scales, while throughput sidesteps estimation debates entirely. Fourth, explain when to prefer each: use throughput with cycle-time percentiles to build probabilistic forecasts and service level expectations, especially when stakeholders ask when work will be done; use velocity for short-term capacity calibration within a single team that has a stable estimation baseline. Fifth, mention Little's Law implicitly by noting that throughput connects to work in progress and cycle time, so improving throughput usually means finishing current items before starting new ones rather than working faster.
The mistakes people make
A red flag is saying throughput is just velocity without story points. That misses the point that throughput ignores size and estimation completely. Another red flag is claiming velocity is useless; senior candidates should show nuance by explaining where velocity still helps, such as sprint planning for a single stable team. A third red flag is confusing throughput with bandwidth or resource utilization; throughput is a count of completed work items, not hours spent or people busy.
What usually comes next
The interviewer may ask how you would introduce throughput to a team currently addicted to velocity. They may ask how throughput interacts with cycle time and work in progress under Little's Law. They may also ask how you forecast delivery dates without points, or how you compare throughput across teams with different item sizes.
A concrete example
Suppose a stakeholder asks when a backlog of thirty items will be done. If you rely on velocity, you must first estimate every item in points, debate relative sizing, and then divide by the team's average velocity, which ignores variability. If you rely on throughput, you look at the last eight sprints and see the team finishes six to nine items per sprint. You then check your cycle-time scatterplot and see that eighty-five percent of items finish in ten days or less. You can tell the stakeholder that thirty items will likely take three to five sprints, with an eighty-five percent confidence level, without estimating a single point.
Interview question
A stakeholder asks when a 40-item backlog will likely be complete. The team wants to avoid estimation debates and provide a probabilistic forecast. What is the best approach?
- a.Use velocity by estimating all items in story points and dividing by the team's average sprint capacity.
- b.Use throughput by tracking total hours the team is busy each sprint to calculate resource utilization.
- c.Use throughput by counting recent items completed per sprint and combining with cycle-time percentiles to forecast.Correct
- d.Use velocity but ignore story points and count items completed, since throughput is just velocity without points.
Why? this is the answer
Throughput counts actual items finished and pairs with cycle-time percentiles to create probabilistic forecasts without estimating. Option D is wrong because throughput is not simply velocity without story points; it fundamentally ignores estimation and size, whereas velocity depends on team-specific point scales.
Just read this? Test yourself on what you have been reading.
Read the original → kollabe.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
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