Team velocity is one of the most useful metrics in agile project management, providing teams and stakeholders with insights into delivery capacity and helping to forecast completion dates more accurately. This guide explains how to calculate velocity, interpret it correctly, and use it to improve your agile planning process.
What Is Team Velocity?
Velocity is a measure of a team's delivery capacity within a time-boxed iteration (usually a sprint). It's calculated by summing the story points or other relative sizing units of all completed work items at the end of each sprint.
For example, if your team completes user stories worth 35 story points in a two-week sprint, your velocity for that sprint is 35 points per sprint.
Why Velocity Matters
When tracked consistently, velocity provides several benefits:
- Predictable planning: Teams can forecast how much work they can commit to in future sprints
- Realistic release planning: Product owners can estimate when a set of features might be completed
- Insight into improvements: Changes in velocity over time can indicate process improvements or emerging issues
- Team stability: Stable velocity indicates a well-functioning team with consistent processes
How to Calculate Team Velocity
Step 1: Define "Done"
Before calculating velocity, ensure your team has a clear Definition of Done. Only work items that meet this definition should count toward velocity. This typically means a feature is fully implemented, tested, and ready for deployment.
Step 2: Sum Completed Story Points
At the end of each sprint, add up the story points for all fully completed items. Partially completed work should not be counted—velocity only measures actual delivered value.
Step 3: Track Velocity Over Time
Record your velocity for each sprint and maintain a running average. Most teams look at the average of the last 3-5 sprints as their "current velocity."
Velocity Calculation Example:
- Sprint 1: 28 points
- Sprint 2: 32 points
- Sprint 3: 26 points
- Sprint 4: 35 points
- Sprint 5: 31 points
Average velocity = (28 + 32 + 26 + 35 + 31) ÷ 5 = 30.4 points per sprint
Visualizing Velocity
Most teams track velocity using a simple chart showing points completed in each sprint. A line representing the moving average helps identify trends and stabilization.
Using Velocity for Sprint Planning
Once you've established a stable velocity, you can use it to plan future sprints more effectively:
1. Sprint Capacity Planning
Use your average velocity as a starting point for how many story points the team can complete in the next sprint. Adjust for known capacity changes:
- If team members will be out or new people are joining, adjust proportionally
- If the sprint has holidays or is shorter/longer than usual, make appropriate adjustments
2. Sprint Selection Process
- Sort the product backlog by priority
- Starting from the top, select items until their total points approach (but don't exceed) your average velocity
- Confirm the team's commitment to these items
3. Example
If your team's average velocity is 30 points per sprint:
- Story A: 8 points
- Story B: 5 points
- Story C: 13 points
- Story D: 8 points
- Story E: 5 points
You would likely include Stories A, B, and C (totaling 26 points) and possibly Story D if the team feels confident, bringing the total to 34 points.
Using Velocity for Release Planning
Forecasting Completion Dates
You can use velocity to forecast when a set of features or a release will be completed:
- Sum the story points for all remaining items in the release
- Divide by your average velocity to get the number of sprints needed
- Multiply by your sprint length to get an estimated timeline
Example:
- Remaining work: 180 story points
- Average velocity: 30 points per sprint
- Sprint length: 2 weeks
- Calculation: 180 ÷ 30 = 6 sprints = 12 weeks
Probability-Based Forecasting
For more sophisticated forecasting, consider using a range based on your velocity history:
- Conservative estimate: Use your lowest recent velocity
- Likely estimate: Use your average velocity
- Optimistic estimate: Use your highest recent velocity
This provides stakeholders with a range of completion dates rather than a single point estimate.
Common Velocity Mistakes to Avoid
Using Velocity as a Performance Metric
Velocity is a planning tool, not a performance indicator. Using it to compare teams or evaluate performance often leads to gaming the system by inflating estimates or taking shortcuts on quality.
Expecting Continuous Improvement
While process improvements can increase velocity, expecting constant growth is unrealistic. Once a team stabilizes their process, velocity typically plateaus at a sustainable pace.
Ignoring Context Changes
Changes in team composition, technology, or domain knowledge can significantly impact velocity. When these changes occur, reset your velocity expectations and build a new baseline.
Counting Partial Work
Only count fully completed items. Counting partial work inflates velocity and creates an illusion of progress without delivered value.
Factors That Influence Velocity
Understanding what affects velocity helps teams interpret changes correctly:
Team Stability
Adding or removing team members typically causes temporary velocity drops as the team adjusts to new dynamics.
Technical Debt
Accumulating technical debt often results in gradually decreasing velocity as maintenance costs increase.
Estimation Consistency
Changes in how the team estimates (estimate inflation or deflation) can appear as velocity changes without actual capacity changes.
Process Improvements
Genuine improvements in development practices, automation, or removing impediments can increase sustainable velocity.
Advanced Velocity Practices
Normalized Velocity
Some teams calculate "normalized velocity" by dividing points completed by actual capacity (in person-days) to account for fluctuating team availability:
Normalized Velocity = Points Completed ÷ Actual Capacity Days
Velocity Range Planning
Instead of using a single average, some teams plan using their velocity range from the last several sprints:
- "Committed" items: Can be completed even at the team's lowest recent velocity
- "Forecast" items: Additional items that might be completed if velocity is higher
Velocity Breakdown Analysis
Breaking down velocity by work type (new features, bugs, technical debt) helps teams ensure balance and identify shifts in work focus.
Velocity in Scaled Agile Environments
When scaling agile across multiple teams, velocity considerations become more complex:
Program Increment Planning
In frameworks like SAFe, teams use their velocities to determine capacity for Program Increments, typically spanning 8-12 weeks.
Normalized Story Points
Some organizations standardize story point scales across teams to make velocity somewhat comparable for higher-level planning.
Feature Team Approach
When multiple teams work on shared features, consider tracking "feature velocity" rather than individual team velocities for release planning.
Conclusion
Team velocity is a powerful tool for agile planning when used correctly. By focusing on consistency in measurement, understanding context, and using velocity as a planning tool rather than a performance metric, teams can leverage this data to create more predictable delivery patterns.
Remember that the ultimate goal isn't to maximize velocity but to establish a sustainable pace that delivers high-quality software and maintains team health over the long term.