Development velocity measures how much useful work an engineering team delivers over time. For an engineering manager, it is one signal of success alongside business results, team morale, and operational excellence. section 1.2 section 1.5
Useful ways to examine development velocity include:
- Sprint velocity: track how many story points the team delivers in a sprint, using burndown charts to understand capacity. section 1.2.2
- Delivery flow: consider deployment frequency, change lead time, mean time to recovery, and change failure rate through DORA metrics. section 1.2.2
- Supporting flow: monitor code-review completion time, bugs reported and resolved, and recovery time after failed deployments. section 1.2.2
- Cross-functional outcomes: compare velocity over time with milestones, quality, stakeholder satisfaction, collaboration, knowledge sharing, and return on investment. section 9.2.6
When operational problems reduce velocity
A team’s on-call workload gradually increased because of technical debt and outdated infrastructure. Engineers spent more time resolving problems and less time delivering products, reducing development velocity. A focused improvement effort with site reliability teams restored the team’s delivery capacity. section 1.2.4
Treat velocity as a team signal, not a ranking system. Story points can clarify capacity, task understanding, and estimation accuracy, but comparing individuals, teams, or projects can be unfair. Assess trends over a longer period, preserve quality, and prioritize value delivered over speed. section 1.2.2
