Sprint Velocity Anti-Patterns to Avoid

Identify and fix common velocity anti-patterns including velocity inflation, gaming estimates, ignoring variability, and using velocity as a performance metric.

Improvement

Detailed Explanation

Velocity Anti-Patterns

Velocity is a powerful planning tool when used correctly. But it can be misused in ways that harm the team and produce misleading data.

Anti-Pattern 1: Velocity as a Performance Metric

Symptom: Management compares velocities across teams or ties velocity to performance reviews.

Problem: Teams inflate estimates to show "higher" velocity. A story that was previously 3 points becomes 5. The numbers go up but actual output does not change.

Fix: Use velocity only for planning within a single team. Never compare across teams.

Anti-Pattern 2: Counting Incomplete Stories

Symptom: Half-done stories are counted as partial credit (e.g., "we finished 80% of the 8-point story, so count 6 points").

Problem: This inflates velocity and hides the fact that nothing was actually shipped.

Fix: Binary done/not-done. A story either meets the Definition of Done or it does not count.

Anti-Pattern 3: Ignoring Variability

Symptom: The team uses a single average number without considering standard deviation.

Problem: An average of 30 with a standard deviation of 15 means the team might deliver anywhere from 15 to 45 -- that is not useful for planning.

Fix: Always report velocity as a range using standard deviation.

Anti-Pattern 4: Never Adjusting Estimates

Symptom: Stories are estimated once during refinement and never revisited, even when new information emerges.

Problem: Estimates become stale and velocity loses its predictive power.

Fix: Re-estimate stories at sprint planning if significant new information has surfaced.

Anti-Pattern 5: Optimizing for Velocity Instead of Value

Symptom: The team cherry-picks easy stories to maximize points, avoiding high-value complex work.

Problem: Velocity is high but business outcomes are poor.

Fix: Prioritize by business value, not by story point density. The Product Owner should set priorities independently of estimates.

Use Case

Use this guide during a team retrospective to identify and address velocity misuse, or when coaching management on healthy agile metrics.

Try It — Sprint Velocity Calculator

Open full tool