How to Calculate Project Velocity: A Practical Guide to Useful Forecasts
Measure completed sprint work consistently, understand what the number can and cannot tell you, and use velocity to plan with your team—not to rank people or chase points.
Quick answer
Calculate sprint velocity by adding the estimates for items that are fully done and accepted in that sprint. To find an average, add completed points across several comparable recent sprints and divide by the number of sprints. Use the result as a team-specific planning signal, alongside capacity, scope, and uncertainty. Do not count unfinished work, compare velocity between teams, or treat points as a productivity target.
1. What is project velocity?
Team velocity is the total estimated amount of work a team completes during an iteration. In Scrum, teams commonly express it as story points completed in a sprint. Velocity describes the team's recent delivery pattern; it is not a measure of how hard an individual works.
Velocity gives a team one way to connect its backlog with its observed ability to finish work. If the remaining backlog is about 60 points and a stable team has recently completed around 20 points per sprint, the team might use that history to discuss a rough number of iterations. This is a forecast, not a guarantee. New information, scope changes, dependencies, leave, defects, and team changes can shift the result.
The word “project” can be misleading here. Velocity is most useful as a team-level measure in a timeboxed process where the team uses a consistent estimate scale. It does not describe the value of the work, the speed of a particular employee, or the percentage of a project that is complete. Pair it with outcome measures and direct conversations rather than interpreting it alone.
Teams using continuous flow may find throughput, cycle time, and work-item age more useful than sprint velocity. Choose a measure that matches how work arrives and gets completed. A metric is helpful when it improves a decision, not just because it is easy to calculate.
2. How velocity became an Agile planning tool
Agile teams needed a way to plan iterations without pretending that task estimates were exact hours. Relative estimation offered a shared method for comparing work size and uncertainty. Counting the estimates for items completed in an iteration gave teams a historical planning signal, often called velocity.
Over time, the number was sometimes turned into an external target. That changes the behavior it was intended to support. Teams may inflate estimates, split work unnaturally, or prioritize easy points over useful outcomes when velocity becomes a score. A healthy practice keeps estimation and velocity local to the team and uses them to improve planning assumptions, not to judge people.
Modern teams can combine velocity with delivery analytics, but the foundations have not changed: a clear definition of done, consistent estimation, and a stable enough context to compare iterations. Automation may summarize patterns; people still need to understand what changed and decide what to do next.
3. What velocity can help a team do
Used carefully, velocity helps a team plan a reasonable amount of work and discuss whether a release forecast is plausible. It can reveal a trend worth investigating, such as a sustained capacity change or work that is repeatedly carrying over.
- Plan iteration scope: use recent delivery as one input when selecting work the team believes it can finish.
- Discuss release ranges: estimate how many iterations remaining work might take, while showing the assumptions.
- Improve estimation: investigate when actual work differs from the team's expectations and refine future sizing.
- Notice context shifts: explain the effect of leave, support duties, a new teammate, or a changed definition of done.
- Support stakeholder conversations: show why a proposed scope or date may need a trade-off.
- Encourage team learning: examine process friction and improve the system that helps work reach done.
Key takeaway
Velocity is a planning input. The team's outcome, quality, and sustainable pace remain more important than a bigger point total.
4. The project velocity formula, with an example
For one sprint, add the estimates for the backlog items that satisfy the team's definition of done by the end of that sprint. Items that are started but unfinished do not count. If the team completed three items estimated at 3, 5, and 8 points, sprint velocity is 16 points.
To calculate average velocity across a set of comparable sprints, sum the completed points in each sprint and divide by the number of sprints. Suppose a team completed 18, 22, 20, and 16 points over four sprints. The average is (18 + 22 + 20 + 16) ÷ 4 = 19 points per sprint. The range, 16–22, is also useful context; it shows that 19 is not a promise for every iteration.
| Sprint | Completed points | Context |
|---|---|---|
| 1 | 18 | Normal capacity and agreed definition of done |
| 2 | 22 | One fewer support interruption than usual |
| 3 | 20 | Typical sprint |
| 4 | 16 | Planned leave reduced availability |
| Average | 19 points per sprint | Use with the observed range and current capacity |
Do not add unfinished points to the sprint total. If a 5-point story is nearly complete but fails the definition of done, it contributes zero points for that sprint under the completed-work rule. When it is later accepted, count it in the sprint where it is completed. This keeps the measure tied to delivered work rather than optimism or effort already spent.
Be clear whether you are calculating a single sprint's result or an average over several sprints. Label the period and units. “19 points per sprint over four recent iterations” is more useful than a bare “velocity is 19,” because it explains what the number actually represents.
5. Calculate velocity step by step
- Agree on a unit. If you estimate in story points, keep the same reference scale for the team. Do not blend hours and points.
- Define done. Confirm the acceptance, testing, review, and integration conditions an item must meet to count.
- Choose a useful history window. Select several recent sprints that resemble the current team and work. Three to six can be a starting point, not a universal rule.
- Collect completed work. Use the team's board or sprint record and include only accepted items completed within each sprint.
- Sum each sprint separately. Keep the period-level totals so variation and context remain visible.
- Calculate the average and range. Divide the total completed points by the sprint count and note the lowest and highest relevant results.
- Interpret the context. Record capacity, interruptions, team changes, scope changes, and unusual dependencies that may explain variation.
- Use it to discuss a plan. Compare remaining work with recent delivery, then communicate a range and revisit it as evidence changes.
6. Choose a representative sprint history
There is no magic number of sprints that creates a perfect baseline. Use enough recent history to see a pattern, while keeping only periods relevant to the current team and work. If the team has delivered many similar sprints, a longer view may smooth one unusual week. If a major change occurred, a shorter and more relevant period can be more informative.
Keep iteration length and team context consistent
A two-week sprint and a one-week sprint are not directly comparable without context. Nor are totals from teams using different estimation scales. If the sprint duration changes, describe the change and establish a new comparison period. Avoid converting velocity mechanically into another team's scale.
Account for capacity changes without rewriting history
Leave, holidays, support rotations, incidents, onboarding, and training can change how much planned work fits. Keep the actual result for each sprint; annotate the context rather than adjusting completed points to make the data look uniform. During planning, consider current availability explicitly.
Separate scope and estimation changes
If the team changes story point definitions, splits backlog items differently, or refines work during a sprint, the trend may shift even when delivery has not. Note what changed. Avoid restating old work on the new scale unless the team has a clear and consistent reason to do so.
Expert tip
Show the average and the spread together. The range helps stakeholders see why velocity is a forecasting signal rather than a guaranteed commitment.
7. Use velocity for team planning, not performance pressure
Velocity belongs to the team that created the estimates. It is not a measure of an individual developer, Scrum Master, or project manager. Comparing point totals across teams is misleading because teams estimate different work with different references, definitions, and histories.
Targets can distort the number. If management asks for velocity to increase each sprint, teams may inflate estimates or select work that yields more points rather than more value. The resulting number stops describing the team's past and becomes a score people try to manipulate. Keep it out of individual performance reviews, compensation formulas, and cross-team league tables.
At sprint planning, the team can use recent velocity as one input alongside the product goal, backlog readiness, availability, dependencies, and confidence. The team decides what is a realistic selection. If circumstances differ from the history, such as half the team being on leave, the plan should reflect current capacity instead of treating the average as a quota.
8. Compare traditional and AI-assisted velocity forecasting
A basic forecast can use average velocity to estimate how many iterations a backlog may take. A more cautious approach uses a range of recent results and discusses how much work is likely to fit under current conditions. AI-based tools may analyze more history and surface patterns, but they still depend on reliable data and a stable understanding of the team's work.
| Dimension | Traditional forecasting | AI-assisted forecasting |
|---|---|---|
| Inputs | Completed sprint estimates, backlog, capacity, and team discussion | Those inputs plus permitted historical delivery and workflow patterns |
| Strength | Simple assumptions are easy for the team to inspect and explain | Can summarize more history and flag changing patterns |
| Best fit | New teams, short histories, or work with limited comparable data | Stable teams and workflows with enough reliable, relevant history |
| Risk | Manual forecasts may over-rely on one average or stale data | Missing context or biased records can produce misleading precision |
| Governance | Team reviews assumptions and owns the commitment | People verify inputs and predictions; the team remains accountable |
For example, if the backlog has 60 estimated points and the team's recent range is 16–22 points per sprint, a rough capacity-based view might suggest roughly three to four sprints. That arithmetic alone is not a release commitment. It assumes the backlog is sized consistently, the scope is stable, the team's capacity resembles the history, and dependencies do not introduce new waiting. Communicate those assumptions and revisit them as work progresses.
When using AI, confirm which data is included, whether that data is approved for the tool, and who can access it. Review predictions for missing context such as team changes, unusually large support demand, or scope that has not been estimated. Do not let an algorithm turn local estimation into a performance ranking.
9. Implement velocity tracking without extra bureaucracy
- Start with a planning question. For instance, “What amount of ready work is a sensible selection for our next sprint?”
- Agree on estimation and done. Explain the unit and acceptance conditions before looking at the totals.
- Capture sprint results in the normal workflow. Use the board the team already updates; do not build a parallel report unless needed.
- Review the number with the team. Look at completed work and ask what affected flow or capacity.
- Use it with other planning information. Consider backlog readiness, dependencies, product goals, and upcoming availability.
- Communicate the range and assumptions. Explain what the forecast includes and what could change it.
- Inspect outcomes, not just estimates. Learn whether the delivered work achieved its intended result and met quality expectations.
- Remove reporting that does not help. Keep only the history and measures that support real decisions.
FlowUpBoard teams can use a shared project-management workflow to keep tasks, estimates, ownership, and progress visible. The tool does not define good velocity practice on its own; the team agrees on its estimation scale and completion rules. Learn how FlowUpBoard works and use only the views that help your planning conversation.
10. Twenty practical project velocity examples
These examples show how teams can interpret velocity in context. The point totals are illustrative only; they are not benchmarks or recommended targets.
1. Four-sprint average
Results of 18, 22, 20, and 16 average to 19 points per sprint.
2. Unfinished story
A 5-point item not accepted by sprint end contributes zero that sprint.
3. Partial availability
Record leave context and plan less work rather than forcing the historic average.
4. Production support
Review interrupt load when fewer planned items reach done.
5. New team member
Account for onboarding time and revisit the forecast as the team learns.
6. Changed sprint length
Annotate the change and build a comparable baseline for the new cadence.
7. Estimation reset
Mark the new scale and avoid treating it as directly comparable to old totals.
8. More testing added to done
Expect the trend to reflect the fuller quality bar, not assume a decline in effort.
9. Work carried over
Count it when completed, and inspect why it did not meet done earlier.
10. Release backlog
Use a velocity range with estimated remaining work to discuss possible iteration counts.
11. Scope added mid-sprint
Make the change visible and avoid calling extra scope a failure to meet the original plan.
12. Public holiday
Note the reduced working days when comparing that sprint with normal periods.
13. Cross-team dependency
Explain when waiting, not estimation, prevented completion.
14. Similar sprint history
Select periods with the same team, duration, and done rule for a useful average.
15. One unusual sprint
Show the range and context rather than deleting a low or high result to polish the mean.
16. Team capacity changed
Use current availability during planning even if the historical average is higher.
17. Comparing two squads
Do not compare totals; discuss each squad's own trends and outcomes.
18. Kanban flow
Consider throughput and cycle time when the team does not plan fixed sprints.
19. AI forecast suggestion
Check data quality, team context, scope, and assumptions before using it.
20. Stakeholder date request
Explain the forecast range and choices that could alter scope or timing.
11. Adapt velocity and forecasting to your work
Software product teams
Story points may help a Scrum team plan a sprint, but include integration, testing, review, and release work in its definition of done. Use outcomes and quality measures alongside velocity. For continuous flow, cycle time and throughput may provide clearer delivery forecasts.
Consulting and professional services
Work can vary in uncertainty and client response time. Keep assumptions and client dependencies visible, and do not use a team's internal estimate scale as a billing measure unless a separate contract explicitly defines that relationship.
Marketing and creative teams
Creative tasks can differ greatly in research, stakeholder review, and revision cycles. A relative estimate may support team discussion, but velocity is meaningful only if the work units and completion criteria remain consistent.
Operations and support
Demand may arrive continuously and vary by urgency. Rather than forcing a sprint metric onto a service workflow, track throughput by service class, work age, and cycle time. Make incident work visible so planned work can be adjusted.
Startups and small teams
Keep measurement lightweight. If velocity helps the team choose a manageable sprint, track it. If estimates create overhead or the workflow is continuous, use simpler evidence such as completed work, active items, and time to finish.
For related guidance, read about sprint planning, task estimation, team workload tracking, project deadlines, and Kanban WIP limits.
12. Five illustrative velocity case studies
Note: These fictional composite scenarios are educational examples, not claims about named FlowUpBoard customers or independently verified performance results.
Case 1: A new Scrum team establishes a baseline
A newly formed product squad had no delivery history and felt pressure to match a neighboring team's points. They agreed on a done rule, estimated their own work, and reviewed three early sprints as learning data.
Illustrative result: sprint planning became a team-owned discussion instead of a comparison exercise.
Case 2: Support work explains a lower sprint total
A team saw velocity fall during a period of elevated customer incidents. The retrospective made support work visible, and the product lead reserved capacity for the next sprint.
Illustrative result: the forecast reflected actual demand and did not label the team as underperforming.
Case 3: A team clarifies its definition of done
One squad started counting code-complete stories while another required testing and acceptance. They agreed on a shared quality rule for their own work and stopped comparing the totals across squads.
Illustrative result: velocity became more consistent within the team and less tempting to misuse as a benchmark.
Case 4: A release forecast adds uncertainty
A product owner divided estimated backlog points by average velocity and presented one exact date. The team instead shared a range based on recent results and identified dependencies that could change the schedule.
Illustrative result: stakeholders could discuss scope options with more realistic expectations.
Case 5: A flow team chooses a better measure
An operations group accepted requests continuously and did not work in sprints. They tried sprint velocity but found that it obscured urgent incoming demand, so they reviewed throughput and cycle time by work type.
Illustrative result: the team's forecast matched its workflow more closely.
13. Ten best practices, common mistakes, and FAQs
- Count only accepted work. Keep the definition of done clear and consistent.
- Use one team's scale. Do not compare point totals between teams.
- Show the history and range. An average without context can imply false certainty.
- Choose relevant sprints. Use history from a comparable team, cadence, and type of work.
- Plan with current capacity. Leave, support, and changes still matter even when history is stable.
- Use velocity as one input. Consider backlog readiness, risk, dependencies, and product outcomes.
- Keep estimates local. Do not turn points into individual hours or performance scores.
- Explain changes honestly. Note shifts in scope, team, estimation, or quality rules.
- Review trends with the team. Ask what helped work finish and what created waiting.
- Choose a better measure when needed. Flow teams may forecast with throughput and cycle time instead.
Common mistakes to avoid
Do not count partially completed stories as a fraction of velocity. Do not increase estimates to make a chart look better. Avoid treating the average as a commitment for every sprint, comparing teams, or assuming a higher total means more value. A changed team, sprint duration, or definition of done can make historical comparisons weak. Explain those limits instead of hiding them.
Warning: velocity can be gamed
When people are rewarded or punished for point totals, estimates stop being honest planning tools. Keep velocity at the team level and use it to learn about delivery—not to evaluate individual performance.
Future trends and practical next steps
Planning software may increasingly combine historical velocity, cycle time, work-item age, and current capacity to propose forecasts. These tools can make patterns easier to see, but they cannot know every quality concern, priority trade-off, or change in team context. Begin with clean data, transparent assumptions, and a human review. Next sprint, agree on one definition of done, calculate completed work, and ask whether the number helped the team make a better plan.
Related articles
Project velocity FAQs
Conclusion: make velocity useful, not intimidating
Calculate velocity from work the team actually completed under a consistent definition of done. Use a relevant sprint history, show the range, and discuss the context behind changes. Then combine the result with current capacity, dependencies, and product outcomes to make a forecast the team can explain.
FlowUpBoard can help keep work and progress visible in a shared workflow. Explore our features, pricing, and more guidance on the blog. Learn about FlowUpBoard or contact us about your team's workflow.
Make team planning easier to see
Build a shared view of work, owners, and progress, then make more informed delivery decisions.
Talk to FlowUpBoard