There's a moment in a lot of standups that nobody names out loud. The team is underwater, everyone knows it, and when planning poker comes around a story that's honestly a three gets called a five. Nobody argues. Not because anyone's lying. Because the number has quietly stopped being an estimate and turned into a shield.
I've watched that happen on teams I was supposed to be protecting. The velocity chart looked great the entire time. That's the part that should bother you.
Most posts about velocity want to tell you it's a bad metric and you should stop measuring it. I don't think that's right. Velocity is a fine planning tool. It helps a team figure out how much it can reasonably take on. The problem isn't the number. It's the job we promoted the number into, why it got promoted, and what that costs you that never shows up on the chart.
So here's my actual claim: velocity didn't fail. It succeeded at the wrong job. It became the cheapest way for a team's work to look productive to the people above it, and that cheapness is exactly why the real bill, burnout and the attrition that follows it, stays invisible until someone hands you a resignation letter.
The metric that travels
Think about everything that happens inside a single sprint. Someone does a careful refactor that'll save the next person a week. A teammate is clearly fried and pushing through anyway. A quiet architecture decision dodges a month of pain six months from now. The on-call rotation chews up two people's focus. None of that compresses well. None of it fits on a slide.
Velocity does. It's one number, it trends on a chart, and it survives the trip from the team room to the VP's dashboard intact. So it gets overweighted, not because anyone's malicious, but because it's the signal that's actually available. Leadership reports velocity for the same reason you reach for the flashlight that has batteries in it.
when a measure becomes a target, it stops being a good measure. —Charles Goodhart
The trouble starts the moment that number becomes a target. Goodhart's law covers it: when a measure becomes a target, it stops being a good measure. The instant velocity turned from a planning aid the team owned into a performance number management owned, the estimates started drifting up. The three becomes a five. Coverage targets get hit by tests that assert nothing. The metric keeps climbing and tells you less every quarter.
Which brings up the objection that every honest version of this conversation has to answer. A VP says: "If I stop tracking velocity, how do I know the team is delivering?"
Here's the uncomfortable answer. You didn't know before either. Velocity was never proving how much a team could deliver. It was proving how busy the team looked. A team can hit its committed points every sprint and ship a pile of features nobody uses. John Cutler named this the feature factory: a story-point machine where the work gets celebrated by the unit and no one stops to ask whether any of it actually worked. A green velocity chart is fully compatible with shipping nothing of value. If that sentence stings, it's doing its job.
Redefine "done" so it includes the people doing it
If you change one thing, change what "done" means.
When "done" means the story is merged and the points are claimed, a team that's quietly drowning still looks done every single sprint. The definition of done can't see the debt the team is taking on to hit it. So the debt accrues silently, sprint after sprint, while every dashboard stays green.
A definition of done that ignores whether the team can do this again next sprint isn't a definition of done. It's an IOU you're writing against your own people.
This is where team health stops being a soft topic. The researchers behind the SPACE framework, the developer-productivity model out of Microsoft, GitHub, and the University of Victoria, found that developer satisfaction works as a leading indicator. Not a feel-good footnote. An early warning system. When satisfaction drops while output holds steady, you're not fine. You're building hidden burnout that shows up later as attrition and a quiet collapse in quality. A fifteen percent satisfaction drop at stable velocity is a forecast, not a vibe.
Sit with what that means next to the velocity chart. The number that travels upward most easily is the one that structurally cannot show you the risk that costs you the most. Your team can be one bad quarter from losing two senior engineers, and velocity will report "on track" right up to the exit interview.
That's the case for putting sustainability inside your definition of done. Not as a wellness perk. As the only place in your process that's actually watching the signal your delivery metrics are blind to.
Give the number-keepers something better to report
Here's the part most of these arguments skip. You can't just tell a Product Owner or an engineering manager to stop reporting velocity and walk away. They answer to someone. Take away their number without handing them a better one and you've just asked them to go dark upstream, which no one with a job is going to do.
So give them the replacement. This is what DORA metrics are for: lead time for changes, deployment frequency, change failure rate, and mean time to restore. Two of those measure speed to value, two measure stability. They travel upward as cleanly as velocity does, and they're a lot harder to game without genuinely getting better. You can inflate an estimate. You can't fake a low change failure rate. The number gets better only when the system does.
Pair that with how you talk about the work. Instead of "we burned forty-seven points," the report becomes "we shipped the thing that lets customers do X, here's the lead time behind it and here's our failure rate." A sprint goal is the unit of value. Report the goal and the quality behind it, not the volume of tickets that fed it.
One honest warning, because the alternative to one bad metric is not four shiny ones. Goodhart's law applies to DORA too. Turn deployment frequency into a target and someone will start splitting deploys to juice the count. Swap a single weaponized number for four and you've rebuilt the same machine with more dials. The fix was never a better leaderboard. The fix is refusing to let any one metric become the whole story, and keeping velocity where it belongs: inside the team as a capacity check, off the executive slide as a verdict.
What "done" should actually mean
The version of done I want is simple. The work shipped, and the team isn't starting the next sprint already in debt.
Velocity will tell you the first half of that sentence. It will never tell you the second. That's not a flaw you can tune out with a better burndown chart or a cleaner Jira board. It's the job the metric was never built to do. Asking velocity to report team health is like asking the speedometer whether the driver is tired.
Measure what you ship. Measure whether it worked. And measure, separately and on purpose, whether the people who built it can do it again. Ship code, stay human. The second part doesn't show up on the chart, which is exactly why it's the one you have to go looking for.
