If you pay for software development, you’ve probably seen a velocity chart. Story points per sprint, trending up and to the right, presented as proof the project is on track. It feels like a speedometer. It isn’t.
We first wrote about this in 2023, for engineers. This version is for the person paying the invoice.
Speed is not velocity
Speed is how fast something moves. Velocity is speed with a direction. Speeding to New York is great, but not if you were supposed to be in Florida.
What most teams call velocity is just speed: how much work got done. It says nothing about whether it was the right work. Developing something fast is only valuable if it’s the right thing. And the word does something sneaky. Everyone understands there’s a limit to how fast a team should go, that going too fast is unsafe. Call it velocity and that concern fades. The word hides the risk it’s supposed to reveal.
What the number can’t tell you
It measures output, not outcomes. Forty points of features shipped is meaningless if the dispatcher still does end-of-day in a spreadsheet. The number doesn’t know whether anyone is using the feature, whether the process got faster, or whether the KPI you funded the project for has moved. We build to outcomes. Velocity can’t see them.
It’s a lagging indicator. Velocity reports what happened last sprint. By the time it drops, the problem it’s reporting has been live for weeks and has already hit your timeline. You want to hear about the roadblock before it shows up in a chart, which means someone telling you in plain English the week it appears, not a trend line a month later.
It gets gamed the moment it becomes a target. Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. Tell a team their velocity needs to go up and it will go up. Estimates inflate. Stories get split in half. Corners get cut on testing. The number improves and the software doesn’t. That isn’t dishonesty. It’s what any group of people does with a metric they’re judged on.
It assumes a predictability that doesn’t exist. Software work is uneven. A hard integration, a requirement that changed, a vendor API that behaves differently than its documentation says. Velocity treats all of that as noise around a steady average. Plan on the average and you’ll be surprised, repeatedly, and always in the same direction.
Where velocity is fine
Inside the team, it’s useful. If the team finished around thirty points last sprint and nothing’s changed, committing to about thirty next sprint is sensible. If someone’s on vacation, commit to less. That’s the whole legitimate use: a planning aid for the people doing the work.
It should never be the number reported upward as progress. The moment it leaves the team, it turns into everything described above.
What to ask for instead
You’re paying for outcomes. Ask for evidence of outcomes.
- Working software, on a schedule. Not a demo of a screen. Something you or your people can click through on a real environment every couple of weeks. If a partner can’t show working software early and often, no chart makes up for it.
- Hardest thing first. Ask which part of the build is riskiest and when it will be proven. If the answer is “the integration, in month five,” the project’s real risk is hiding behind easy points now.
- Time to value. When does the first user do real work in the system? Minimizing that is the number that matters most.
- Scope against budget, in plain English. What’s done, what’s left, what’s changed, and whether it still fits. We work to a fixed budget with controlled scope, so the status report is a scope report, not a point total.
- The KPI. Every build should be aimed at something measurable: hours removed, days sales outstanding down, error rate down, quotes out the same day. Ask what it is and where it stands.
If your team or partner answers those and also tracks story points internally, fine. If they answer with a velocity chart and nothing else, you have a reporting problem, and there may be a project problem underneath it.
If the chart looks great and nothing ships
That combination, rising velocity and no usable software, is the most common shape of a project in trouble that we see. Points are being earned. Value isn’t. Sometimes it’s the team, sometimes it’s the scope, often it’s that nobody ever wrote down what done means.
It’s worth being blunt about the incentive here. A team billing by the hour and reporting velocity has every reason to keep the chart rising and no particular reason to ship. A team working to a fixed budget with controlled scope has the opposite incentive: the only way to finish well is to get working software in front of you and find out early whether it’s right.
The one question to ask this week
Ask your team or partner: “What can a real user do in the system today that they couldn’t do last month?” A good answer is specific and demonstrable. A bad answer talks about points.
If you own a system mid-build and the honest answer worries you, a System Evaluation is one to four weeks at a fixed fee and tells you where the project actually stands. If the build has stalled outright, that’s project rescue. If you’re about to start something new and want the reporting set up right from day one, how we work covers it, and a discovery call is 30 minutes.