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.
Understanding the Fundamentals
Before diving into calculation methods, it's essential to understand that velocity is unique to each team. A velocity of 30 points for Team A doesn't mean the same as 30 points for Team B. This is because story point estimates are relative and team-specific, reflecting each team's collective understanding of complexity, effort, and uncertainty.
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
- Data-driven decision making: Velocity provides objective data for capacity planning and resource allocation
- Stakeholder transparency: Clear metrics help communicate realistic timelines to stakeholders
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.
Your Definition of Done might include criteria such as:
- Code written and peer-reviewed
- Unit and integration tests passing
- Documentation updated
- Acceptance criteria validated
- Product owner approval obtained
- No known defects
A consistent Definition of Done ensures that your velocity measurements remain comparable across sprints and reflect actual delivered value rather than partially completed work.
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.
This discipline is critical. Counting partially completed work inflates your velocity numbers and creates a false sense of progress. If a story is 90% done but doesn't meet your Definition of Done, it contributes zero points to that sprint's velocity.
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."
Why use an average? Individual sprint velocities naturally fluctuate due to:
- Team member availability (vacations, sick days)
- Sprint length variations (holidays)
- Unexpected technical challenges
- Changing requirements
Averaging smooths out these fluctuations and provides a more reliable planning metric.
Velocity Calculation Example
Consider a team tracking velocity over five sprints:
- 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
This team would use approximately 30 points as their planning velocity for upcoming sprints.
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.
Create a velocity chart with:
- X-axis: Sprint numbers or dates
- Y-axis: Story points completed
- Bar chart: Actual velocity per sprint
- Line graph: Moving average (3-5 sprint window)
This visualization makes it immediately obvious when velocity is trending up, down, or remaining stable, and helps identify outliers that warrant investigation.
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
- Account for time needed for ceremonies, production support, or other non-development activities
For example, if your average velocity is 30 points but you know two team members will be out for half the sprint, you might plan for 24-25 points instead.
2. Sprint Selection Process
Follow this systematic approach:
- 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
- Include a buffer for unexpected work or uncertainties
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.
However, many experienced teams prefer to commit conservatively to 26-28 points, knowing that completing early creates opportunities to pull in Story D during the sprint if capacity allows.
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
This provides stakeholders with a data-driven estimate for release timing.
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.
Example using the data above:
- Conservative (26 points): 180 ÷ 26 = 7 sprints = 14 weeks
- Likely (30 points): 180 ÷ 30 = 6 sprints = 12 weeks
- Optimistic (35 points): 180 ÷ 35 = 5 sprints = 10 weeks
Communicating a range (10-14 weeks) sets more realistic expectations than a single date and accounts for natural variability in software development.
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.
Each team's velocity is unique to their context, estimation scale, and Definition of Done. Comparing velocities across teams is meaningless and counterproductive.
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.
A stable velocity is actually a sign of team maturity and predictability—exactly what you want for reliable planning.
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.
For example, if two experienced developers leave and are replaced by junior developers, expect velocity to temporarily drop while the new team members come up to speed.
Counting Partial Work
Only count fully completed items. Counting partial work inflates velocity and creates an illusion of progress without delivered value.
This is one of the most tempting mistakes. It feels discouraging to "lose" points from a story that's nearly complete. However, maintaining discipline here ensures velocity remains a reliable planning metric.
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.
New members need time to understand the codebase, team conventions, and product domain. Even experienced developers will reduce team velocity initially while they're onboarding.
Technical Debt
Accumulating technical debt often results in gradually decreasing velocity as maintenance costs increase.
If velocity trends downward over time despite consistent team composition, technical debt is often the culprit. Each new feature becomes harder to implement as the codebase becomes more brittle and complex.
Estimation Consistency
Changes in how the team estimates (estimate inflation or deflation) can appear as velocity changes without actual capacity changes.
Teams should periodically calibrate their estimation process by reviewing completed stories and confirming that point values still reflect relative size accurately.
Process Improvements
Genuine improvements in development practices, automation, or removing impediments can increase sustainable velocity.
Examples include:
- Implementing continuous integration/deployment
- Reducing code review turnaround time
- Automating repetitive tasks
- Improving development environment setup
- Resolving chronic technical issues
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
This approach helps distinguish between velocity changes due to availability versus productivity. For example:
- Sprint 1: 30 points with 100 person-days = 0.30 points per person-day
- Sprint 2: 24 points with 75 person-days = 0.32 points per person-day
Despite lower absolute velocity, Sprint 2 actually had higher productivity per available person-day.
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
This approach provides flexibility while still maintaining a clear commitment to stakeholders about what's guaranteed versus what's possible.
Velocity Breakdown Analysis
Breaking down velocity by work type (new features, bugs, technical debt) helps teams ensure balance and identify shifts in work focus.
If velocity remains constant but an increasing percentage goes to bug fixes, that's a warning sign about quality issues. Conversely, dedicating some velocity to technical debt is a healthy investment in long-term productivity.
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.
Each team contributes their expected velocity for the increment, allowing program-level planning around features that may require coordination across teams.
Normalized Story Points
Some organizations standardize story point scales across teams to make velocity somewhat comparable for higher-level planning.
However, this approach should be used cautiously. Even with standardized scales, team-specific factors mean velocities still aren't directly comparable. Use normalized points for rough capacity planning, not for performance comparison.
Feature Team Approach
When multiple teams work on shared features, consider tracking "feature velocity" rather than individual team velocities for release planning.
This focuses planning on delivered value (complete features) rather than individual team output, better reflecting the reality of cross-team dependencies.
Tools for Tracking Velocity
Modern teams have several options for tracking and visualizing velocity:
- Jira, Azure DevOps, or similar tools: Built-in velocity tracking and reporting
- Spreadsheets: Simple and flexible for custom calculations
- Physical boards: Velocity charts posted in team spaces for high visibility
- Alignlee: Use Planning Poker for consistent estimation, which improves velocity reliability
The best tool is the one your team will actually use consistently. Start simple and add sophistication only if needed.
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.
Ready to improve your team's estimation and velocity tracking? Try Alignlee's Planning Poker tool to build estimation consistency and make velocity a more reliable planning metric for your team.
Frequently Asked Questions
Q: What's a good velocity for an agile team?
There's no universal "good" velocity. Velocity is team-specific and depends on your estimation scale and Definition of Done. Focus on stability rather than absolute numbers.
Q: Should we count carried-over stories in velocity?
No. Only count stories when they're fully completed according to your Definition of Done. If a story carries over to the next sprint, it counts toward that sprint's velocity when completed.
Q: How many sprints before velocity stabilizes?
Most teams see velocity stabilize after 3-5 sprints. New teams or teams undergoing significant change may need more time to establish a reliable baseline.
Q: Can we use velocity to compare different teams?
No. Velocity is not comparable across teams due to different estimation scales, team sizes, and Definitions of Done. Use velocity only for planning within a single team.
Q: What if our velocity is decreasing?
Investigate potential causes: accumulating technical debt, team changes, scope creep, or estimation drift. Hold a retrospective to identify and address the root cause.