We're Still Wrong About Velocity

We're Still Wrong About Velocity

Shipping every last idea in the backlog is not likely to drive revenue or user counts, and shipping bad ideas headed the wrong direction comes with the risk of decreasing what matters.

We're Still Wrong About Velocity

Velocity is speed and direction. It's displacement over time if you want to be technical, but for us amateur physicists I'm sticking with speed and direction. It has always been hard to know if we're going in the right direction though.

I've been in a lot of rooms where velocity only means how much can be shoved into 2 weeks. And yes, refinement should be reorienting priority to head the right direction. That requires protection of scope, little asks, bad ideas, good ideas, and now the entire backlog of any ideas.

It also only works if you know the direction, and can measure success in a meaningful time frame. Using AI coding you can now clear out the entire roadmap and backlog in no time. If it's always been hard to know if we're going in the right direction, how do AI enabled teams know they're not going in the wrong direction 10x faster?

Commit to the need

You have to commit to measuring direction. It's easy to only measure speed because speed is easy to measure. Speed without direction gets you somewhere, but direction ensures it's not into a wall or over a cliff.

Identify who can provide clarity


You don't need to see where you're going, but you need to know what the signs mean you've arrived. Someone has that vision if it's not you. This is where you spiral as long as you can until there's a clear answer because it's cheaper to spend time cycling on the imagined future than rebuilding a release.

This vision isn't going to look the same every place you go. It might be user outcomes, it might be contract signatures, it might be decreased churn. Product parity, padded egos, and proof an idea can actually be stood up are all possibilities as well.

As the product manager, understand how to judge direction

You are the intent evaluator for the team. You got the clarity, now it's time to evaluate that displacement. Pick the signals that will ensure you're heading to the right direction, and include the timeframes needed to validate.

I am using these words on purpose, because evaluations and LLM-as-a-judge are tools you would use to evaluate work and product in an AI-enabled delivery team, but the skills of judgement and evaluation are already there and deserve to be named. These are all forms of technical requirements.

Maybe speed out the door is right for the current state of the project, to get a signal on direction but it only provides enough info to iterate. Your signals might need multiple iterations to get clearer and closer over time. Your goal is evaluation points along the way to check the direction is pointing toward the outcome, not that the outcome was met.

Likewise, big swings, strange bets, and R&D might be too bleeding edge to feel an outcome. Your evaluations might be around if the team can pivot and adapt and deliver. The communication of those requirements is what will help ensure they are met.

Put as much of your brain as you can into your team. They should understand the ultimate direction, and they should understand the intent of achieving those outcomes. They need to have a calibrated idea of where fast, good, and cheap fall for the tasks. This all ensures multiple points where outcome is evaluated, so it's not all a one time inspection but a continual process.

So then what should be velocity?

Speed and direction... (speed x direction) actually.

What have I completed? X points.

Was it pointed at the right heading? Yes or No, per pointed item.

Now you should have on-target and off-target identified.

You can stop here if you want with the understanding that misdirected points contribute zero to velocity. Yep. Just go ahead and don't count them.

But if you are an amateur physicist, mathematician, or numbers person we can see a formula though to the same end.

Your speed is the number of completed points.
Your direction ratio is the number of on-target points รท total completed points.
Your corrected velocity is speed x direction ratio.

The last step should always return only the on-target point count, because that's the only velocity that doesn't carry risk of being wasted time.

If Story 1 was 8 points and is on-target directionally, but Story 2 was 5 points and is off-target directionally, I am suggesting that your velocity is only 8.

Maybe she just hates velocity

I'm likely not your user, so tweak it how you want, give yourself partial credit, etc. but I think when we can build anything we need to be more critical about what we're building. Shipping every last idea in the backlog is not likely to drive revenue or user counts, and shipping bad ideas headed the wrong direction comes with the risk of decreasing what matters. Hold yourselves accountable to craft, value and quality. You have the ability to care more about direction than speed when the speed is being outsourced.