Why is tracking team velocity as a KPI dysfunctional?
Tests if you know velocity is for planning, not performance. Explain it's easily gamed and measures output, not outcome. Propose metrics focused on value delivery and process improvement like cycle time.
What's really being asked
This question tests your understanding of core agile principles and anti-patterns. It specifically probes whether you can distinguish between a team's internal planning tool (velocity) and a business-level performance indicator. The interviewer is looking for a senior candidate who can articulate why focusing on velocity is destructive and can confidently guide leadership toward metrics that foster trust, continuous improvement, and actual value delivery, steering them away from Taylorist micromanagement.
The full answer
First, define velocity's correct purpose: it is a qualitative gauge, not a quantitative control. It's an observation of work completed in past sprints, used by the team itself to forecast its capacity for future sprints. It is not a measure of productivity or performance.
Second, explain the specific dysfunctions. Using velocity as a KPI is harmful because it's based on subjective estimates (points), not measurable units. Per Goldratt's Law, "Tell me how you measure me, and I will tell you how I will behave," teams will inevitably game the system through point inflation. This incentivizes shipping large quantities of low-value work over tackling complex, high-value problems. It measures output, not outcome, and wrongly punishes teams for doing difficult, valuable work that takes longer than estimated.
Third, propose superior, actionable alternatives. Suggest metrics that focus on process improvement and value delivery. Good examples include Cycle Time (time from starting work to completion), Lead Time (time from request to delivery), deployment frequency, and direct measures of customer value like Net Promoter Score (NPS) or user retention figures.
The mistakes people make
Accepting the premise and suggesting ways to "normalize" velocity across different teams is a major red flag; it shows a fundamental misunderstanding. Another is defending velocity as a performance metric if "used correctly." A weak answer criticizes velocity without offering concrete, superior alternatives. Proposing other vanity metrics like "lines of code" or "number of commits" is also a poor response, as they suffer from similar flaws.
What usually comes next
Be prepared for follow-ups that test your influence and communication skills, such as: "How would you explain this to a non-technical VP who just wants one number to track progress?" or "If a team's velocity drops from 40 to 20, isn't that a clear sign of a problem?" They may also ask, "If we don't use velocity for long-term planning, what should we use?"
A concrete example
Imagine a manager offers a bonus for the team with the highest velocity. Team A's velocity was 30 points/sprint. They start inflating estimates, turning 3-point stories into 8-pointers. Their velocity jumps to 70, but they're delivering the same low-complexity work. Team B, meanwhile, tackles a critical 25-point refactoring project that eliminates significant tech debt. Their velocity is only 25. The KPI rewards Team A for gaming the system while punishing Team B for delivering high, long-term value. The focus shifts from value to points.
Interview question
What is the primary reason why tracking team velocity as a Key Performance Indicator (KPI) is considered dysfunctional?
- a.It discourages teams from undertaking critical but time-consuming tasks like refactoring, which can temporarily lower point counts.
- b.It is an internal planning tool, not designed for external performance measurement or cross-team comparison.
- c.It relies on subjective estimates, which teams can easily game, leading to inflated numbers that prioritize output over actual value.Correct
- d.It fails to account for the quality of work or the long-term impact on the product, focusing only on quantity.
Why? this is the answer
The card highlights that velocity's subjective nature allows for gaming (point inflation) when used as a KPI, shifting focus from valuable outcomes to mere output. While velocity is indeed an internal planning tool (Option B), the core dysfunction as a KPI stems from its susceptibility to manipulation and its misdirection of team effort.
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