Velocity You Can Feel
Velocity should be qualitative, not quantitative, in early and growth-stage startups
Like what you see? Product snacks delivered fresh to your inbox.
Get bite-sized visual articles like this one delivered straight to your inbox.
I have the somewhat controversial opinion that most efforts to measure velocity (things like story points and burn-down charts) are at best not worth the effort and counterproductive to company success.
Instead, the focus should be on shipping work that has an impact. Actively track the impact of what you’re building and shipping, consistently share what’s happening with stakeholders and customers alike, and focus your quantitative efforts on impact instead of how many tickets your engineers ship each sprint.
The issue isn’t that trying to increase velocity is inherently wrong. There are two significant issues with measuring velocity quantitatively: 1) misalignment with what’s best for the company, and 2) the opportunity cost of time spent measuring.
Misalignment
Running faster in the wrong direction only gets you further off track. When you make it clear that moving faster is the goal and hold people to a quantitative measure of that, it’s natural for everyone to put the blinders on and have a singular focus on driving velocity. To have a good result from quantitative measurement, you need to carefully manage the whole process to ensure the system near-perfectly captures an accurate representation of value. By contrast, in a well-run and empowered team, you can rely on a shared understanding of what’s important, and everyone involved can apply their judgment to move in the right direction. When you add a metric to the mix, there’s a significant incentive to defer to moving the metric instead of “doing what’s right.” It certainly doesn’t make it impossible; it just makes it harder. And do we really want to make our work harder?
Opportunity Cost
There’s meaningful time and effort required to manage velocity measurement and management. There’s the basic logistics, but there’s also less obvious things like trying to standardize point sizing across teams, managing stakeholder expectations, limiting the incentive to game the system, consistently advocating that velocity is part of the puzzle and not the only thing that matters. What if you took all that energy and spent it on something that generated tangible value?
Worth noting, while I’m not an advocate of story points and detailed estimation, the point I’m making isn’t to say you shouldn’t do that. It’s how you use it. For example, if you’re estimating so that the team better understands the work, that’s still a great idea. Don’t do math or make charts with the story points as a rule of thumb, and you should be fine.
