tezvyn:

What is throughput and how does it differ from velocity?

Curated by the Tezvyn teamSource: kollabe.comintermediate
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 THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.

Source: kollabe.com

Read the original → kollabe.com

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.