Why is velocity as a primary KPI destructive, and what's better?

WHAT THIS TESTS: This question tests whether you understand the difference between an observational gauge and a management control, and whether you recognize that Agile is built on trust and continuous improvement rather than Taylorist measurement. The interviewer wants to see that you know story points are subjective judgments, not objective quantities, and that turning velocity into a target triggers gaming, fear, and value destruction.

A GOOD ANSWER COVERS: First, define velocity correctly as a planning gauge based on observed averages of completed work, not a lever management can pull. Second, explain that a story point is a qualitative judgment made with incomplete information, so deriving a quantitative performance metric from it is mathematically invalid. Third, cite Goldratt's principle that people optimize for whatever is measured, which means a team asked to hit 200 points per sprint will simply inflate estimates, split stories artificially, or pull low-value easy work to maximize the number while hurting actual outcomes. Fourth, note that velocity as a KPI signals distrust, invites micromanagement tools like individual velocity tracking, and tells teams that estimate accuracy matters more than work quality or customer value. Fifth, propose alternatives aligned with the reference: replace top-down KPIs with a culture of continuous process improvement where the team itself identifies and acts on small, actionable, real-world signals immediately; evaluate success by whether the team is delivering real value and improving its own workflow, not by output volume.

COMMON WRONG ANSWERS: A common wrong answer is claiming velocity is fine if you average it over many sprints or normalize it across teams. Another red flag is suggesting individual velocity comparisons to identify low performers, which the reference explicitly calls abhorrent and abusive. Proposing to make estimates more precise so velocity becomes reliable is also wrong, because all estimates in Agile are based on incomplete information by definition. Finally, offering a dashboard of output metrics without addressing trust or worker-controlled improvement misses the core critique entirely.

LIKELY FOLLOW-UPS: An interviewer might ask how you would convince a skeptical executive to abandon velocity KPIs. They might also ask what you would do if a team currently reports velocity to leadership every sprint and wants to stop. A third follow-up could be how you detect improvement without any numbers at all, pushing you to explain qualitative assessment and observable team behaviors.

ONE CONCRETE EXAMPLE: Imagine a manager sets a target of 200 points per sprint for a team. The team knows the number is arbitrary, so they break every story into tiny pieces, pad estimates, and pick the easiest backlog items. The dashboard shows green: velocity is up. Meanwhile, the customer receives low-value features that do not solve their problems, technical debt accumulates because refactoring carries no points, and a developer who spent a week solving a critical bug is reprimanded for low individual velocity. The metric is met and the system is broken.

Source: holub.com