When Velocity Lies: A Hybrid Team's Hard Lesson
A product team I worked with — call them the Atlas team — spent the first half of 2021 split across three time zones, half at home and half rotating through a thinned-out office. Like a lot of groups that year, they were still absorbing supply hiccups, sick days, and the general churn of pandemic recovery. Their Scrum Master proudly tracked one number above all others: velocity. It had climbed from 28 to 41 points a Sprint in four months, and leadership loved the chart. The problem was that almost nothing was actually shipping.
Velocity is a useful planning tool. It is also one of the easiest measures in Scrum to fool yourself with. The Atlas team's story is worth telling because their mistakes were ordinary, not exotic — and the fix did not require a new tool, just honesty.
How the number drifted from reality
When we looked closely, three things were inflating the count without adding value to the customer.
Estimates crept upward. Under pressure to "show improvement," the team quietly started sizing similar work higher. A task that was a 3 in March became a 5 by June. The chart rose; the work did not change.
Points were claimed for unfinished work. Items that were "basically done" got counted at Sprint end, then quietly reopened the next week. Velocity borrowed against the future.
Definition of Done had eroded. With testers stretched thin across hybrid schedules, "done" came to mean code merged, not tested and releasable. The increment was not actually usable.
None of this was dishonest in intent. It was a team trying to look healthy while quietly drowning. But velocity had stopped describing delivered value and started describing the team's optimism.
Putting honesty back in
The Scrum Guide is clear that the Increment must meet the Definition of Done to be releasable, and that only Done work counts. We started there. The team restored a strict Definition of Done — tested, integrated, and demonstrable — and agreed that anything not meeting it carried over at zero credit. Velocity dropped to 22 the next Sprint. Leadership flinched. We held the line.
Velocity is for the team's own forecasting, never a target handed down or compared across teams.
Estimate relative size, then leave the scale alone; re-baselining mid-stream destroys the signal.
Count only what meets the Definition of Done at Sprint Review — no partial credit, no IOUs.
Watch trend over several Sprints, not any single number; a noisy week tells you little.
Within five Sprints the honest number settled around 26 and, more importantly, the Sprint Review finally showed working software the Product Owner could release. The team's forecasts became trustworthy again, which mattered far more to stakeholders than a flattering chart. Hybrid work had made the drift easy to hide; transparency was the only durable cure.
The lesson is plain. Velocity measures nothing on its own — it only has meaning when paired with a Definition of Done you actually honour. The moment a metric becomes a goal, people optimize the metric instead of the outcome. A consultant or coach can help, but mostly the team has to want the truth more than the pretty line.
If your delivery metrics are telling a story that does not match what you are shipping, XNM's program & project delivery advisory can help you rebuild measures your stakeholders can trust.