Velocity in Agile: Formula, Chart & How to Use It [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 21, 2026
9 min read
Velocity is the most useful number in agile and the easiest one to abuse. Used as a forecasting tool, it turns a team's own track record into a credible answer to "when will this be done?" Turned into a performance target, it quietly rots into a game of inflated estimates that measures nothing. The difference is entirely in how you use it. This guide explains velocity in agile in full — what it is, the formula, a worked example, how it drives planning, how it differs from capacity, its pitfalls, and how it is tested on the PMP and CAPM exams.
What is velocity in agile?
Velocity is the amount of work a team completes in a single sprint, measured in the same unit the team estimates with — usually story points. If a team finishes stories worth 24 points in a sprint, its velocity for that sprint is 24.
The one rule that keeps velocity honest is that it counts only work that fully meets the definition of done. A story that is 90% finished contributes nothing to velocity — there is no partial credit — because velocity is meant to reflect delivered, shippable work, not effort in progress. That strictness is what makes velocity a reliable planning number rather than an optimistic one, and it is why velocity is always a measure of a specific team's completed output, not a universal rate.
How to calculate velocity
Velocity is a simple average. You add up the story points a team completed across several recent sprints and divide by the number of sprints:
> Average velocity = total story points completed ÷ number of sprints
Take a team's last three sprints:
| Sprint | Story points completed |
|---|---|
| Sprint 1 | 22 |
| Sprint 2 | 26 |
| Sprint 3 | 24 |
| Average velocity | 24 points per sprint |
The average is (22 + 26 + 24) ÷ 3 = 24 points per sprint. Teams use an average of the last three to five sprints rather than a single sprint, because any one sprint can be thrown off by a holiday, an illness, or an unusually hard story. A new team's velocity is volatile at first and settles into a stable range after a few sprints — which is the point at which it becomes trustworthy for forecasting.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
How velocity is used
Velocity earns its keep in two planning jobs. The first is sprint planning: a team that averages 24 points knows roughly how many points to pull into the next sprint, so it commits to a realistic amount rather than over- or under-loading itself.
The second is release forecasting. Divide the work remaining in the backlog by the average velocity, and you get the number of sprints to finish it. A 120-point backlog at a velocity of 24 points per sprint is about five sprints of work — which, multiplied by the sprint length, gives a credible release date grounded in the team's real track record instead of wishful thinking. This forecasting use is exactly what a release burnup chart visualizes over time.
Velocity vs. capacity
Velocity and capacity are often confused, but they answer different questions and point in opposite directions in time. Velocity looks backward — it is the work a team has actually completed in past sprints. Capacity looks forward — it is the time or effort a team has available for the upcoming sprint, after accounting for holidays, part-time members, and other commitments. Here is the comparison:
| Velocity | Capacity | |
|---|---|---|
| What it measures | Work completed per sprint | Available time for the next sprint |
| Direction | Backward (historical) | Forward (planned) |
| Unit | Story points | Hours or person-days |
| Used for | Forecasting how much fits and when | Planning the next sprint's commitment |
The two work together. Velocity gives the baseline expectation — "we usually do about 24 points" — while capacity adjusts it for the specific sprint ahead: if three team members are on holiday next sprint, capacity is lower, so the team commits to less than its average velocity. Velocity is the trend; capacity is the reality check for the sprint in front of you.
What affects velocity
Velocity is not a fixed property of a team — it shifts with circumstances, which is exactly why it should be read as a trend, not a single number. The main things that move it:
- Team changes. Adding, losing, or swapping members changes velocity, often dropping it temporarily while a new member ramps up.
- Availability. Holidays, illness, and time split across projects reduce the work a sprint can absorb.
- Story complexity and unknowns. A sprint full of risky, unfamiliar work tends to complete fewer points than one of well-understood work.
- Estimation drift. If a team quietly changes how it sizes stories, velocity moves without any real change in output.
Because of all this, a single sprint's velocity means little on its own. What matters is the average and its stability over time. A one-sprint dip because half the team was on holiday is not a problem to solve; it is normal variation the average already smooths out.
Common velocity pitfalls
Velocity is simple to calculate and dangerously easy to misuse. The traps that do the most damage:
- Using velocity as a target. The moment velocity becomes a goal to hit or a performance metric, teams inflate their estimates to "go faster" on paper. The number rises; the actual delivery does not.
- Comparing velocity across teams. Because points are relative to each team, one team's 40 and another's 25 are not comparable — ranking teams by velocity punishes honest estimation.
- Expecting velocity to always rise. A healthy velocity stabilizes; it does not climb forever. Pressure to keep increasing it is pressure to inflate.
- Counting unfinished work. Giving partial credit for almost-done stories inflates velocity and destroys its value as a forecast of shippable work.
The common thread is treating velocity as a measure of productivity rather than a tool for planning. Keep it a forecasting aid the team owns, and it stays useful; turn it into a scoreboard, and it stops telling the truth.
Velocity on the PMP® and CAPM® Exams
Because agile and hybrid approaches are a large part of the PMP exam, velocity appears as a core agile metric. The facts to lock in: velocity is the story points a team completes per sprint; it counts only work that meets the definition of done; the average of recent sprints is used to forecast; and it is relative to a team, so it is neither comparable across teams nor a valid productivity target.
The situational questions almost always test a misuse — a manager setting a velocity target, comparing teams, or pressuring a team to raise its number — and reward protecting velocity's role as a team-owned forecasting tool. Being able to calculate it from a few sprints and forecast a release from the backlog is also fair game. The CAPM tests the same ideas a little more directly, often the definition or a simple calculation. Our PMP Complete Study Guide, the most complete on the market, covers agile metrics and the mindset that keeps them honest.
PMP Practice Question: Velocity in Agile
A stakeholder asks the project manager to commit to a release date based on the team's velocity. The last six sprints show 30, 12, 29, 13, 31, and 14 points completed, an average of about 21.5, and the team plans roughly 30 points of work every sprint. The product owner suggests simply using the six-sprint average for the forecast.
What should the project manager do next?
a) Use the six-sprint average of about 21.5 points, since averaging across more sprints is exactly how velocity absorbs normal variation.
b) Investigate why velocity alternates between the low teens and low thirties before forecasting, since the pattern suggests work is regularly spilling across sprint boundaries.
c) Base the forecast on about 13 points per sprint, the demonstrated low end, so the commitment holds even in the worst observed case.
d) Base the forecast on roughly 30 points per sprint, since that is what the team consistently plans and reflects its capacity when work flows well.
Correct answer: B.
Rationale: The clue is the shape of the data, not its average: velocity that alternates high, low, high with near-perfect regularity is not normal variation — it is the signature of large stories spilling into the next sprint, because velocity gives no partial credit, so a story finished one sprint late lands all of its points in the following sprint. Until that cause is confirmed, every number on the table misleads in its own way: the average blends two alternating states without describing either, the planned 30 measures intent rather than throughput, and the low 13 measures the spillover rather than the team's capacity. Investigating first, and typically splitting the oversized stories, both stabilizes the cadence and turns velocity back into something a release commitment can safely stand on. To drill this kind of forecasting judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is velocity in agile?
Velocity is the amount of work a team completes in a single sprint, measured in the unit the team estimates with, usually story points. It counts only work that fully meets the definition of done, with no partial credit. Averaged over several sprints, it becomes a reliable basis for forecasting how much a team can deliver.
How do you calculate velocity in agile?
Add up the story points a team completed across several recent sprints and divide by the number of sprints: average velocity = total story points completed ÷ number of sprints. For example, sprints of 22, 26, and 24 points give an average velocity of 72 ÷ 3 = 24 points per sprint. Teams typically average the last three to five sprints.
What is the velocity formula?
The velocity formula is average velocity = total story points completed ÷ number of sprints. Only stories that fully meet the definition of done are counted. Using an average across several sprints, rather than a single sprint's number, smooths out normal variation from holidays, absences, or unusually hard work and gives a stable figure for planning.
What is the difference between velocity and capacity?
Velocity is the work a team has completed in past sprints, measured in story points — a backward-looking forecasting number. Capacity is the time or effort a team has available for the upcoming sprint, measured in hours or person-days — a forward-looking planning number. Velocity sets the baseline expectation; capacity adjusts it for the specific sprint ahead.
Is a higher velocity better?
Not necessarily. Velocity is a planning tool, not a score, and it is relative to each team, so a higher number does not mean a better or more productive team. A healthy velocity stabilizes rather than climbing forever, and pushing a team to raise it usually just inflates story-point estimates without increasing real delivery.
Is velocity on the PMP exam?
Yes. Agile and hybrid approaches are a large part of the PMP exam, and velocity is a core agile metric it tests. You are expected to know that it is the story points completed per sprint, that it counts only done work, that it forecasts a release when divided into the backlog, and that it is not a valid cross-team or performance measure.
Is velocity on the CAPM exam?
Yes. The CAPM covers agile metrics including velocity, usually a little more directly than the PMP — often defining it or asking for a simple calculation from a few sprints. Because the CAPM is scenario-based, you should still be ready to apply velocity as a forecasting tool in a short situation.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
