Velocity Tracking Best Practices
How should we properly track velocity? Do we include incomplete stories? What about bugs? Our velocity swings from 15 to 40 points per sprint and management thinks we're unpredictable.
Only count fully DONE stories (Definition of Done met). Bugs get estimated and counted same as features - they're work. The swings suggest either wildly inconsistent estimation or scope creep mid-sprint.
Track separately: planned velocity vs actual. If planned is 30 but actual is 40, you're pulling in work - bad. If planned is 40 but actual is 15, you're over-committing. Aim for ±10% variance.
Use 3-sprint rolling average. Single sprint velocity is meaningless noise. We chart: (1) Rolling avg velocity, (2) Sprint commitment vs completion rate, (3) Velocity trend line. This shows management predictable capacity without sprint-to-sprint panic.
Separate planned vs unplanned work. We track 'sprint commitment' (what we planned) vs 'sprint interrupts' (urgent bugs, production issues). If interrupts are >20% of your velocity, you have a quality problem. Makes it visible to management why velocity fluctuates.