Why is team velocity a poor KPI for agile success?
Tests your grasp of agile principles and Goodhart's Law. Explain velocity is for forecasting, not performance. Detail dysfunctions like point inflation and ignoring quality. Propose outcome-focused alternatives like cycle time.
What's really being asked
This question tests your understanding of core agile principles, specifically that metrics should drive improvement, not serve as performance evaluations. It assesses your ability to articulate the dysfunctions caused by misusing metrics, a concept summarized by Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure." Interviewers are looking for senior-level thinking that moves beyond output (story points) to outcomes (customer value) and demonstrates an ability to educate management on healthy practices.
The full answer
A good answer makes three points. First, it defines velocity correctly as a team-specific, backward-looking gauge for capacity planning and forecasting, not a measure of performance or productivity. It's based on subjective, relative estimates (points), not objective units of work, so it cannot be used for quantitative analysis. Second, it describes the specific dysfunctions. This includes story point inflation (teams arbitrarily increase estimates), ignoring quality and technical debt to close more tickets, and creating unhealthy competition between teams. It incentivizes quantity over value. Third, it proposes better metrics. A strong answer suggests flow metrics like Cycle Time (time from starting work to completion) and Lead Time (time from request to delivery), which measure the health of the delivery process. It also includes outcome-based measures like customer satisfaction (NPS), business-impact metrics (e.g., conversion rate), and team health surveys.
The mistakes people make
A major red flag is trying to "fix" velocity as a KPI, for example, by suggesting ways to normalize points across teams. This is impossible and misses the fundamental point. Another weak answer is criticizing the metric without offering concrete, actionable alternatives. Simply saying "velocity is bad" without proposing better options like cycle time shows a lack of practical experience. Finally, any suggestion of comparing team velocities is a classic anti-pattern; a candidate who suggests this does not understand the purpose of estimation.
What usually comes next
Expect questions like: "How would you explain this to a non-technical manager who is demanding a single number for performance?" or "If we can't compare teams, how do we identify which teams need help?" or "Cycle time sounds great, but how do we account for stories of different sizes?"
A concrete example
"At a previous company, management started a 'Velocity Leaderboard.' Within two sprints, our team's velocity 'doubled' from 25 to 50 points. We didn't get faster. We just started estimating every story at double the points and stopped doing any refactoring or writing comprehensive tests. We hit the target, but code quality plummeted, and our bug count tripled in the following quarter. This is a classic example of Goodhart's Law in action."
Interview question
If management begins tracking team velocity as a primary performance indicator (KPI), what is the most likely outcome based on Goodhart's Law?
- a.The team will produce more accurate forecasts for future sprints.
- b.The team's reported velocity will likely increase, without a corresponding increase in value or quality.Correct
- c.The team's cycle time will decrease as they become more efficient at completing work.
- d.Teams will collaborate to create a standardized, comparable scale for story points.
Why? this is the answer
Correct. Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. Teams will optimize for the target (more points) by inflating estimates or cutting quality. Attempting to standardize points is a common anti-pattern, making it a tempting but incorrect option.
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