Your Teams Are Moving Faster. Why Isn’t Anything Shipping?
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
Engineering leaders often see rising velocity charts while feature delivery actually stalls, a pattern illustrated through a fictional scenario in the book Signals & Levers by Elisabeth Hendrickson and Joel Tosi. Story points measure activity, not progress, and become gamed once treated as a target—an instance of Goodhart's Law. The real bottleneck is often structural: work stuck at the seams between teams, not within them. The suggested fix is to track feature cycle time or lead time instead of team velocity, separate 'are we delivering' from 'are we busy,' and avoid overreacting to normal variation in delivery metrics.
Table of contents
Focus On Moving Somewhere Interesting, Not ActivityWhat Theresa Discovered—and What You Can Do InsteadThe Instinct to React Is the ProblemQuestions this post answers
Why does team velocity go up while feature delivery gets slower?
Velocity measures activity, not progress, so when it becomes a target teams optimize for hitting the number rather than for shipping. This is Goodhart's Law in practice: story points get assigned to code reviews, regression tests, and partial work to keep numbers stable. The real cause is usually structural, with work stuck at handoffs between teams rather than within any single team. Engineering leaders debating better delivery metrics can follow this discussion on daily.dev.
What should I measure instead of sprint velocity to know if features are actually shipping?
Track feature cycle time or lead time, the elapsed time from when work starts to when it ships, rather than story points completed per sprint. Cycle time reflects the outcome that matters, users getting features, while velocity is a proxy for effort that teams learn to game once it becomes a target used for evaluation. Teams rethinking how they track delivery can keep tabs on these ideas via daily.dev.
Why does a feature spanning three teams show no progress on any team's velocity chart?
Velocity is tracked per team, so a cross-team feature shows zero progress on every team's chart until it is fully complete and deployed, even while each team logs points for their own piece of the work. Faster individual teams do not produce faster features when the actual bottleneck is coordination, integration, and cross-team dependencies rather than individual team speed. Anyone untangling cross-team delivery bottlenecks can track this thinking through daily.dev.