Agile Velocity: Calculation Examples and Forecasting Limits
Published:
Last Updated:
Agile velocity measures the amount of work a team completes in a fixed period, usually a Sprint. When the team estimates in story points, add the points of completed items. Several comparable Sprints provide a useful basis for forecasting future work.
Velocity is local to the team’s estimation scale and completion standard. It is not an individual performance score or a reliable way to rank different teams.
Calculate completed work
For point-based measurement, velocity is the sum of the story points of items completed during the Sprint. If items worth 3, 5, and 8 points are complete, velocity is 16. Do not add half of an unfinished five-point item simply because someone considers it half done.
Atlassian’s velocity report documentation describes completed work and its average across Sprints. Check the specific reporting rules of your tool, including item types and changes after the Sprint begins.
Sprint | Initial planned points | Completed points |
|---|---|---|
1 | 24 | 18 |
2 | 22 | 22 |
3 | 24 | 20 |
Total | 70 | 60 |
In this fictional example, average velocity is 60 ÷ 3 = 20 points. Dividing the 70 planned points by three would measure something different. Keep the observed range of 18–22 visible alongside the average.
Turn velocity into a conditional forecast
With 100 estimated points remaining and an average velocity of 20, the simple forecast is five Sprints. Using the illustrative range of 18–22 gives five to six whole Sprints after rounding up. At two weeks per Sprint, that is a planning range of ten to twelve weeks.
This calculation assumes a comparable team, estimation scale, completion standard, and work mix. Holidays, dependencies, new discoveries, and scope changes can invalidate the assumptions. Present the result as a forecast and refresh it when the backlog changes.
Make the data comparable
- Compare equal Sprint lengths.
- Agree what counts as complete, including required testing and checks.
- Maintain reference items for relative estimation; see Story Points and Planning Poker.
- Define aggregation rules to avoid counting parent items and their subtasks twice.
If an unfinished item moves forward, do not count it in the previous Sprint’s completed work. Make any treatment of remaining work explicit. Rewriting estimates only to improve the chart destroys the history needed for forecasting.
Investigate changes before drawing conclusions
When velocity falls, first inspect capacity: leave, membership changes, and interruptions. Then inspect waiting, large items, testing, and rework. Finally, check whether the estimation approach or completion standard changed.
More points do not necessarily mean more customer value. Pair work-volume data with quality and outcome measures. Use Burndown and Burnup Charts to inspect remaining work within a Sprint, and Retrospective Frameworks to decide which working practice to improve.
Should velocity always rise?
No. A compulsory target can reward inflated estimates rather than useful delivery. The aim is sustainable planning and better forecasting. Annotate unusual Sprints rather than selectively removing inconvenient results.
Keep delivery forecasts connected to campaign decisions. Xtrategy’s project management features bring task progress, costs, and approval information into a project context, helping teams discuss the operational decisions around their work.
