Throughput vs. Velocity in Agile Planning

What's really being asked

This question assesses your practical experience with agile metrics beyond the basics of Scrum. It's testing whether you understand the difference between measuring actual, observable output (flow metrics) versus measuring estimated effort. A senior candidate should be able to articulate why one is often a better predictor of delivery than the other and in what context.

The full answer

A strong answer will cover four points in order. First, define both terms clearly: Throughput is the number of work items completed per unit of time (like a week or a sprint). Velocity is the sum of story points for work items completed in a sprint. Second, explain the core difference: Throughput is a direct measure of output (a count), while velocity is a measure of estimated effort completed. Third, state the preference: For forecasting and sprint planning, throughput is often more reliable because it's based on historical fact, not estimation accuracy. It answers "how many items can we do?" directly. Velocity is a capacity planning tool for the team, not a forecasting tool for stakeholders. Fourth, provide a scenario: Use throughput for sprint planning by looking at the historical range (e.g., "we usually finish 7-10 items per sprint") and use velocity for internal team discussions about capacity or the relative size of upcoming work.

The mistakes people make

A major red flag is treating the terms as synonyms. Another is claiming velocity is more "accurate" because it accounts for item size. This misses the point that story points are estimates, not facts, and are prone to inflation and debate. A weak answer will just define the terms without explaining the practical implications for forecasting. Saying "it depends" without explaining what it depends on is also a sign of shallow understanding.

What usually comes next

Expect questions about other flow metrics. "How does Work in Progress (WIP) affect throughput and cycle time?" (Hint: Little's Law). Or, "If a stakeholder asks 'When will this specific feature be done?', which metric would you use?" (Hint: Cycle Time and its percentile distributions, like an 85% Service Level Expectation). "How would you introduce flow metrics to a team that only uses velocity?"

A concrete example

Imagine a team completes four stories in a sprint: one 8-point, one 5-point, and two 3-point stories. Their velocity for the sprint is 8 + 5 + 3 + 3 = 19 points. Their throughput for the sprint is 4 items. If, over the last 6 sprints, their throughput has consistently been between 4-6 items, we can confidently plan to pull in about 5 items next sprint. Using the velocity of 19 is less reliable because the point values of the next sprint's items are just estimates.