Velocity Deep Dive
summary
Velocity is explained as a measure of output, not customer value, and six anti-patterns are named: treating velocity as a productivity KPI, setting and punishing numeric targets (e.g., 40 points), reporting it outside the team, comparing teams, and using it for individual evaluation. Recommended uses are limited to sprint planning, short-term forecasting (use a recent average like 22–24 → ~24) and inspection; instead track longer‑term outcomes/impact rather than output, adopt SPACE metric categories, and invite stakeholders to sprint reviews so they can see working increments.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 4:11Velocity dangers
- 5:58Velocity defined
- 7:24Velocity anti-patterns
- 8:47Productivity defined
- 10:55Scrum Guide focus
- 12:59Scrum purpose
- 13:20Estimation uncertainty
- 15:04Target velocity issues
- 17:33Realistic goal setting
- 18:16Reporting velocity pros/cons
- 22:47Team evaluation pitfalls
- 24:33Individual velocity harm
- 26:44Cross-team comparisons
- 28:53Quantitative metric traps
- 31:23Scrum Master role
- 34:11Sprint Review importance
- 35:16Output versus outcome
- 38:08Product metric selection
- 39:12SPACE framework
- 41:19Velocity best practices
- 44:13Future forecasts use
- 45:36Inspection and improvement
- 46:37Summary and value focus
related talks
01h 02mAgile Metrics: Velocity is NOT the Goal
41mEscape Velocity - Better Metrics for Software Teams
37mDebugging Engineering Velocity
15mChoosing Quality to Improve Your Team's Velocity
59mSet Your Teams Up for Improved and Enduring Velocity
10mAchieving engineering velocity by optimising developer experience
35mAgility ≠ Speed
15mOptimizing the engineering value stream