On one of the Slack groups I frequent, we were presented with this hypoethetical interview question:

How would you improve velocity on a team you’re working with?

I also asked the question recently on LinkedIn for general feedback. I was pleased to see that many others think about this question the same way I do. Below I’ve included the answer I provided to the Slack group.

The first thing I would do is stop measuring velocity, as it’s a vanity metric and an anti-pattern.

If that answer doesn’t put the interviewer or management off, then there’s a lot more to discuss:

“Velocity” at least as it is usually understood, is far removed from the original intent of story points and estimation, which was capacity planning. When doing capacity planning, what matters is “How much planned work can we accomplish during a sprint?”

When measuring velocity, what’s (almost invariably) measured instead is “How much work did we get done?” Note that these are subtly, but importantly, different, as the latter includes unplanned work. This seemingly small difference makes velocity (as measured this way) worthless for planning.

Addressing the fact that this is an interview question, I see two possibilities:

• It’s intended as a sort of trick question, hoping you’ll say “velocity is a vanity metric” or go into flow engineering, etc.
• Probably much more likely: They actually believe velocity needs to be optimized, and are looking for your answers.

With that in mind, game theory comes into play. What do you hope to achieve? If you want the job at any cost, you probably want to appeal to the hiring manager who believes in measuring velocity, even if you disagree with that approach (as I do).

If your goal is to find a good match between you and your role, then of course, you should answer based on what you truly believe. For me, that would mean explaining why velocity measurement is fraught with problems. If you disagree with me, then you would answer honestly according to your own beliefs.

Or if you believe as I do, and you want the job, but not at any cost, you might take some sort of middle ground with a “Yes, but…” approach, explaining alternatives in ways that might appeal to people who don’t believe alternatives are necessary or desirable. As a simple example, I might respond with something like “I would aim to improve team flow by doing a bottleneck analysis…” This doesn’t actually answer the question of velocity, but most people not familiar with flow engineering won’t notice the subtle change of subject.

What do you think? Do you agree with my view on velocity? How would you respond to this in a job interview?