Hacker News new | ask | show | jobs
by geekjock 1380 days ago
"Using velocity metrics is like looking for your lost keys under the streetlamp because that's where the light is brightest."

^ 100% agree.

Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes.

Metrics like cycle time get a little bit closer, but still fail to account for team context or surface root causes.

2 comments

> Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes.

So what? The question isn't "what helps you fix everything?"

The question is "how useful is velocity?"...without qualification as how you quantified the values. Looking deeper, the question naturally progresses to "what is the most useful metric?" or even "what is a useful metric?" in determining performance (a scary thought experiment for most developers).

Narrowing the scope of the analysis is a necessary step in determining value. Let's dispense with the gaming numbers strawmen and refactoring and testing rigor etc etc.

Theoretically, if it's you (alone) on a project and you have no other external signals about how well features are valued, what singular value, over time, would you look at and judge your progress historically? This is the closest you can get to an abstract vision of (personal) performance on a project divested from all other concerns. I can always look at my LoC.

Given that there isn't one number (or five numbers or five thousand numbers) that can tell you if your engineering team is good or bad, there is no easy mapping between high and low velocity and good and bad, and velocity can't really be compared between teams or even the same team on different projects, it does have uses.

Particularly when a team has multiple projects, looking at each project's velocity helps you see if you're smoothly building out new features, getting bogged down, distracted by bugs in an old project, consistently underestimating the effort required for all things, etc.

It's a terrible target, not good for evaluation, but a handy metric for a PM to quietly check and use to make sure things are proceeding smoothly. The PM should probably know by other means but no one is perfect.