sethdford Velocity Analysis
Use historical velocity data to improve estimates, identify process bottlenecks, and forecast capacity.
Context
You are helping a tech lead analyze sprint velocity data to improve planning. If the user has velocity metrics from recent sprints, use them to ground analysis.
Domain Context
- Agile Metrics: velocity is a tool for planning, not performance management (XP and Scrum communities agree on this distinction)
- Larson: "velocity is a lagging indicator"; it reflects what you've done, not what you can do
- Vacanti's "ActionableAgile" argues cycle time is more useful than velocity for capacity planning
Key principles:
- Velocity is for planning, not judgment: Never use velocity to shame a team. It's a tool to forecast work capacity
- Stability matters more than magnitude: A team with 40-point velocity that varies by 5 points is more predictable than one with 50-point velocity that varies by 20
- Velocity changes signal process changes: If velocity drops, something structural changed (new process, team composition, project type). Investigate before assuming underperformance
Instructions
- Gather historical data: Collect velocity (story points or items completed) from last 8-13 sprints. This sample size lets you see trends and variations
- Calculate average and standard deviation: Example: 8 sprints of data: 38, 42, 40, 45, 39, 41, 43, 37 → average ~40, std dev ~2.6 (stable). This team forecasts reliably at 40 ± 3 points
- Chart the trend: Plot velocity over time. Look for:
- Gradual increase (team improving, stabilizing after new process)
- Sharp drop (process change, team composition change, major incident) — investigate the cause
- High variance (unpredictable; looks like different types of sprints have different velocity)
- Stratify by sprint type: If some sprints have deploys, incidents, or training, separate them. Example:
- Standard sprints: 40 ± 2 points
- Deploy sprints: 32 ± 3 points (lower, because deploy consumes capacity)
- Learning sprints: 35 ± 4 points (lower due to training/onboarding)
- Identify bottlenecks: Velocity drop or plateau often signals a bottleneck. Ask:
- Are code reviews taking longer (blocked on reviewer availability)?
- Are tests taking longer (CI slow, test suite bloated)?
- Is scope creeping (stories growing mid-sprint)?
- Forecast with confidence bands: Don't say "we'll do 40 points next sprint." Say "we'll do 40 ± 5 points with 80% confidence." Use this in roadmaps
- Set realistic commitments: Use average minus 1 std dev as the conservative estimate for sprint commitment. Use average + 0.5 std dev as the optimistic estimate for roadmap planning
- Measure impact of process changes: When you make a change (new CI tool, different refinement process), measure velocity 3 sprints before/after to see if it helped or hurt
Anti-Patterns
- Extrapolating without understanding cause: If velocity drops 20%, LLMs sometimes suggest "work harder" without investigating root cause. Always ask "what changed?" before interpreting velocity shifts.
- Ignoring sprint type variation: LLMs often recommend 40-point sprints without noting that deploy sprints run at 30 points. Use stratified analysis, not an average that mixes types.
- Using velocity to manage people: Velocity is not a performance metric. If you use it to judge individual engineers or blame a team, they'll game the system by inflating estimates. Use velocity only for planning
- Assuming velocity trend is permanent: Velocity trends reverse (team learns, new hire ramps up). Don't assume that a 5-sprint uptrend continues forever. Revise estimates as new data arrives.
Further Reading
- Vacanti, Daniel. "ActionableAgile: Metrics for Predictability." O'Reilly, 2014. Chapters on cycle time and velocity.
- Cohn, Mike. "Agile Estimating and Planning." Prentice Hall, 2005. Chapter on velocity as a planning tool.
- Larson, Will. "An Elegant Puzzle." Chapter on metrics and measurement.