Velocity is the heart of sprint planning. It tells you how much work your team can realistically complete in a sprint, measured in story points. But velocity is only valuable if you track it consistently and accurately. Many teams make critical mistakes that render their velocity metrics meaningless, leading to unrealistic sprint commitments and missed deadlines.
Understanding how to properly calculate, track, and use velocity data transforms sprint planning from guesswork into data-driven forecasting. This guide shows you how to avoid common pitfalls and build a reliable velocity tracking system.
What Is Sprint Velocity?
Sprint velocity is the average number of story points your team completes per sprint over a rolling time window. It accounts for everything that affects your team's capacity: skill mix, meetings, interruptions, holidays, learning time, and technical debt.
Unlike individual developer productivity metrics, velocity measures team throughput. A healthy velocity pattern emerges after 3-5 sprints, giving you a baseline for forecasting future work.
Why Velocity Matters
Velocity enables three critical capabilities:
- Release forecasting: With 100 story points remaining and 25-point average velocity, you can forecast 4 sprints to completion
- Sprint planning: Commit to work matching your velocity, not aspirational targets
- Process improvement: Velocity trends reveal whether process changes are helping or hurting
But these benefits only materialize if your velocity data is clean and consistent.
Common Velocity Tracking Mistakes
Most teams unknowingly corrupt their velocity data with these errors:
Counting Partially Complete Stories
Only count stories that meet your Definition of Done. A story that is 90% complete contributes zero points to velocity. This prevents teams from inflating velocity by starting many stories and finishing few.
If you regularly have stories spilling over between sprints, your estimates are too large. Break stories down until they fit comfortably in one sprint.
Not Accounting for Sprint Length Variance
A 2-week sprint with a 3-day holiday is really a 7-day sprint. If you compare it to a full 10-day sprint, your velocity looks artificially low. Track actual working days per sprint and normalize velocity accordingly.
Similarly, if team capacity changes mid-sprint due to PTO, illness, or onboarding new members, note that in your velocity tracking. Don't compare a 5-person sprint to an 8-person sprint without accounting for the difference.
Including Spikes in Velocity Calculation
Spikes are time-boxed research tasks, not deliverable features. Including spike points in velocity inflates your metrics without increasing actual feature delivery. Track spikes separately if you need to account for research time.
Some teams use a 0-point story type for spikes to track them in the backlog without affecting velocity. This maintains visibility without corrupting metrics.
Cherry-Picking High-Velocity Sprints for Forecasts
Using your best sprint as the baseline for future forecasting sets you up for failure. That sprint was an outlier, not a sustainable pace. Use median or average velocity across the last 5-7 sprints for realistic forecasting.
Outlier sprints should be investigated to understand what made them different. Was it temporarily reduced meeting load? Fewer production incidents? A particularly well-prepared backlog? Learn from outliers but don't forecast based on them.
Accurate Velocity Calculation Method
Follow this process to calculate clean, reliable velocity:
Step 1: Track Last 5-7 Sprints
Use a rolling window of recent sprints. Too few sprints and you're working with insufficient data. Too many sprints and you're including outdated patterns from when your team was different.
For new teams, you need at least 3 sprints before velocity becomes meaningful. Until then, use rough estimates based on team capacity and story size.
Step 2: Only Count Done Stories
Sum the story points for stories that meet your Definition of Done at sprint end. No credit for in-progress work. This forces honest accounting of what actually shipped.
If your Definition of Done includes QA sign-off, deployment to production, or documentation updates, those must be complete for the points to count.
Step 3: Exclude Outlier Sprints
Remove sprints with exceptional circumstances:
- Team offsite or training event that consumed 50% of sprint time
- Major production incident that pulled the team away from sprint work
- Multiple team members out sick simultaneously
- Sprint where you onboarded 3 new team members at once
Document why you excluded these sprints so future you remembers the reasoning. Don't exclude sprints just because velocity was lower than expected—that defeats the purpose of measurement.
Step 4: Normalize for Team Capacity Changes
If your team grew from 5 to 8 people mid-measurement period, your velocity will naturally increase. When using historical velocity for forecasting, account for the current team size.
Simple normalization: Calculate velocity per team member, then multiply by current team size. This gives you a capacity-adjusted forecast.
Example: Team of 6 averaged 30 points/sprint = 5 points per person. After growing to 8 people, forecasted velocity is 40 points/sprint.
Step 5: Use Median, Not Average
Median velocity is resistant to outliers. If your last 7 sprints were 22, 25, 23, 38, 24, 26, 25 points, the median is 25 points. The average is 26.1, pulled up by that one 38-point sprint.
For forecasting and sprint planning, the median gives you a more conservative, reliable target.
Using Velocity for Sprint Planning
Once you have clean velocity data, apply it consistently:
Commit to Work Matching Velocity
In sprint planning, commit to work totaling your median velocity or slightly less. Leave buffer for unplanned work, bug fixes, and production support. A sprint at 80-90% of velocity that finishes everything builds team confidence. A sprint at 120% of velocity that fails demoralizes the team.
Senior engineers may advocate for over-committing occasionally, believing the team can push harder. Resist this. Sustainable pace means working at your measured capacity, not aspirational capacity.
Forecast Completion Dates
For stakeholders asking "when will this feature ship?" use velocity to forecast:
- Feature requires 75 story points of work
- Team velocity is 25 points per sprint
- Forecast: 3 sprints (6 weeks for 2-week sprints)
Add 15-20% buffer for unknowns: "3-4 sprints, so 6-8 weeks." This sets realistic expectations.
Track Velocity Trends Over Time
Graph your velocity sprint-over-sprint. A stable, slightly variable pattern is healthy. Red flags include:
- Steady increase without team growth: Likely estimation drift (baseline shifting, not true improvement)
- Steady decrease: Process problems, technical debt accumulation, or team demoralization
- Wild swings: Inconsistent estimation practices or unstable sprint planning
Investigate trends in retrospectives. "Our velocity dropped from 30 to 22 over 3 sprints. What changed?"
Tools for Velocity Tracking
Most project management tools track velocity automatically if you use them consistently:
- Jira: Velocity chart shows completed story points per sprint
- Azure DevOps: Velocity widget on team dashboard
- Linear: Sprint velocity reports with trend graphs
For teams using simpler tools, a spreadsheet works: Sprint number, completed points, team size, notes on outliers.
Alignlee automatically tracks velocity across estimation sessions, providing historical reference data to improve future estimates. When teams can see how past estimates performed, they naturally calibrate better over time.
Common Questions About Velocity
Can we compare velocity across teams?
No. Velocity is team-specific because estimation baselines differ. Team A's 5-point story is not the same as Team B's 5-point story. Comparing velocities encourages gaming the metric rather than improving delivery.
Focus each team on their own velocity trends, not cross-team comparisons.
Should velocity always increase?
No. Stable velocity is healthy. Velocity naturally increases when teams grow or when they eliminate technical debt that was slowing them down. But chasing velocity improvement leads to estimate inflation without actual improvement.
The goal is predictable velocity, not maximum velocity.
What if velocity is inconsistent?
Investigate root causes:
- Are stories inconsistently sized? Recalibrate your estimation baseline.
- Is scope changing mid-sprint? Strengthen your Definition of Ready.
- Are estimates too large? Break stories down smaller.
- Is unplanned work consuming capacity? Track interrupt load separately.
Inconsistent velocity often reveals estimation or process problems that, once fixed, improve predictability.
Best Practices for Long-Term Velocity Health
Quarterly Velocity Review
Every quarter, review your velocity data in retrospective:
- Calculate average and median velocity for the quarter
- Compare to previous quarter
- Discuss: What changed? What stayed the same?
- Update forecasting baseline if significant shifts occurred
This prevents drift and ensures your velocity remains a useful planning tool.
Recalibrate Estimation Baseline Annually
Once per year, re-estimate a set of reference stories from 6-12 months ago. Compare new estimates to originals. If they differ significantly, your estimation baseline has drifted.
This is natural as teams learn and improve. Acknowledge the shift and establish a new baseline for future work.
Document Velocity Assumptions
Record the context behind your velocity:
- Team size when velocity was measured
- Sprint length (1 week, 2 weeks)
- PTO and holiday patterns
- Any ongoing experiments or changes
When new team members join or stakeholders ask "why is velocity X?", this documentation provides essential context.
Start Tracking Velocity Accurately
Velocity is only valuable when tracked consistently and used honestly. Avoid the temptation to manipulate velocity through estimate adjustments or cherry-picked data. Trust the data, investigate trends, and use velocity to set realistic expectations.
Ready to build reliable velocity tracking into your estimation practice? Alignlee provides historical velocity data and helps teams calibrate estimates over time for more accurate sprint planning.