Distinguish Throughput from Velocity in agile planning
This tests your grasp of outcome (Throughput) vs. effort (Velocity) metrics. Define both: Throughput is item count/time, Velocity is points/sprint. Contrast them by explaining Throughput measures actual delivery, not estimates.
What's really being asked
This question tests if you understand the fundamental difference between measuring output (work items completed) and measuring estimated effort (story points). It probes your ability to move beyond basic Scrum metrics to more sophisticated flow-based forecasting. Interviewers want to see if you can articulate which metric is appropriate for which type of planning or stakeholder question, demonstrating a mature understanding of process metrics.
The full answer
A strong answer will cover four key points in order. First, define Throughput as a simple count of work items finished per unit of time (e.g., per week or sprint), regardless of size. Second, define Velocity as the sum of story points for items completed in a sprint. Third, contrast the two: Throughput is a measure of actual delivery output, while Velocity is a measure of estimated capacity. Throughput is empirical data; Velocity is based on team estimates. Fourth, explain the use cases: prefer Throughput for probabilistic forecasting and answering "when will it be done?" because it relies on historical delivery rates, not estimation accuracy. Velocity is useful for short-term sprint planning and gauging capacity for the next iteration.
The mistakes people make
A common red flag is treating the terms as synonyms or getting the definitions backward. Another mistake is stating that Velocity is "wrong" and Throughput is "right" without context. A senior candidate acknowledges the trade-offs. For example, saying "we stopped using story points because they're useless" is a less nuanced take than "we moved from Velocity to Throughput for long-range forecasting because it gave our stakeholders more reliable date ranges." Stating "our throughput is 30 points" is a clear sign of confusion; throughput is a count of items, not points.
What usually comes next
How would you introduce Throughput to a team that only uses Velocity? How does Work in Progress (WIP) relate to Throughput? Can you explain Little's Law (Average WIP = Average Throughput × Average Cycle Time)? How would you use Throughput and Cycle Time to build a forecast for a stakeholder?
A concrete example
Imagine a team completes eight stories in a two-week sprint. Two were 8 points, three were 3 points, and three were 1 point. The total points are 16 + 9 + 3 = 28. Their Velocity for that sprint is 28 points. Their Throughput for that sprint is 8 items. If a stakeholder asks when a 20-item backlog will be done, you can use the team's average Throughput (e.g., 7 items/sprint) to forecast it will take roughly 3 sprints. Using Velocity for this forecast would require estimating all 20 items first, which is often impractical and less accurate for date-based predictions.
Interview question
When a stakeholder asks for a reliable forecast of "when will this large backlog of features be done?", which metric is generally more appropriate to use, and why?
- a.Velocity, because it reflects the team's estimated capacity and complexity for future work.
- b.Velocity, as it provides a consistent measure of output that can be directly mapped to the total estimated points of the backlog.
- c.Throughput, because it simplifies planning by removing the need for detailed story point estimations for every item.
- d.Throughput, because it relies on historical delivery rates of completed items, offering empirical data for probabilistic forecasting.Correct
Why? this is the answer
The card explains that Throughput is preferred for probabilistic forecasting and answering "when will it be done?" because it relies on historical delivery rates of actual items, making it empirical data. While Velocity measures estimated capacity, the card notes it is less accurate for long-range, date-based predictions for a large backlog.
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