Story points began as a relative sizing tool. Somewhere along the way they became a productivity metric — and once a number is on a chart, teams optimize for it.
Cycle time is harder to fake. The clock starts and stops on events in your VCS. It points at the work, not the worker.
The trouble with story points
Two-pointers inflate to threes. Carryover gets reframed as 'split.' The burndown looks healthy while production waits. Velocity answers 'how busy were we?' not 'how fast did value reach users?'
That does not mean estimation is useless. It means estimation and delivery speed are different conversations — and conflating them is how retros turn into arguments about points instead of bottlenecks.
What cycle time reveals
Cycle time — from first commit to merge, or from open to production — names the bottleneck. A long review queue, a flaky CI step, a dependency on another team: the metric shows the stage, not a vague 'we were slow.'
DevInsights breaks cycle time into coding, review, CI, and deploy. The team argues about the right stage instead of defending a headline number.
How to introduce it without drama
Do not retire velocity overnight. Run both for one sprint. Let retro conversations compare what each metric claims.
- Publish stage-level cycle time alongside your existing board
- Ask in retro: which stage moved, and what one change would shrink it?
- Celebrate shrinking review wait, not smaller point estimates
Key takeaways
- Velocity measures activity; cycle time measures flow.
- Stage breakdowns turn arguments into targeted fixes.
- Introduce cycle time beside velocity — let retro do the convincing.
