Why is velocity as a primary KPI destructive, and what's better?
This tests if you see velocity as a planning gauge, not a performance metric. A strong answer notes points are subjective, cites Goldratt on gaming, and proposes team-driven improvement instead. A red flag is claiming velocity works if averaged over time.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
A director mandates a 20% velocity increase next quarter for bonuses. What systemic behavior is most certain to follow?
- a.Teams will remove impediments and sustainably increase the customer value delivered per sprint
- b.Teams will refine estimation techniques until story points become objectively consistent across sprints
- c.Velocity variability will naturally disappear once averaged across enough sprints to normalize noise
- d.Teams will inflate estimates and select easier work to hit the target while real outcomes degradeCorrect
Why? this is the answer
Goldratt's principle states people optimize for whatever is measured, so a velocity target incentivizes gaming through inflated estimates and easy work, destroying real value. Distractor B reflects the common misconception that targets drive genuine improvement rather than fear and metric manipulation.
Just read this? Test yourself on what you have been reading.
Read the original → holub.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