What Is Velocity in Project Management?

In project management, velocity is the amount of work a team completes in a set period, usually measured in story points or completed tasks per sprint. Teams use it to forecast how much they can realistically take on next.

Quick note before we go further, this isn’t velocity from physics class, and it has nothing to do with the car brand. In project management it means something simpler and more useful: how much your team actually gets done in a set period of time. Measured across a few cycles, that one number becomes one of your best planning tools.

Planning comes down to one question: how much to take on. Velocity answers it with evidence instead of optimism. Once you know what your team has actually delivered over the last few cycles, the next commitment rests on a track record, which makes it easier to hit and easier to defend in front of a stakeholder. It is one of the core project management terms worth knowing.

---

How is velocity calculated?

Velocity is the sum of the work completed in a cycle. The math is simple. The discipline is in being honest about what “completed” means.

If your team uses story points, you add up the points for every item finished in the sprint. Sprint one: 18 points. Sprint two: 22. Sprint three: 20. Your average velocity is 20 points per sprint. That is the number you plan against going forward.

If you do not use story points, you can count completed tasks instead, as long as the tasks are roughly comparable in size. The unit matters less than the consistency. Count the same way every cycle.

Two rules keep the number trustworthy:

• Only count what is truly done. Half-finished work does not count. A task that is “almost there” is zero until it crosses the line. Counting partial work inflates velocity and breaks the forecast.
• Average across several cycles. One sprint tells you nothing. Three to five sprints give you a range you can plan against. Expect some bounce. A team is not a machine.

What is a good team velocity?

There is no universal good number, and chasing one will lead you astray. Velocity is relative to your team, your point scale, and your work. A velocity of 40 on one team and 15 on another tells you nothing about which team is better, because they are not measuring the same thing.

A good velocity is a stable, predictable one. You want a number that holds steady enough to forecast with, and trends gently upward as the team gets better at estimating and removing friction. Wild swings sprint to sprint are the signal worth paying attention to, because they usually mean estimates are off or work is getting interrupted.

So stop comparing your velocity to other teams. Compare it to your own last quarter.

---

How is velocity used in agile?

In agile, velocity is the bridge between planning and reality. It began as a Scrum measure, and the idea is simple: at the start of a sprint, the team looks at its average velocity and pulls in roughly that much work. Not more because it is there, not less because the week feels heavy. The average is the anchor.

Over time, velocity also feeds longer forecasts. If you have 200 points of work in the backlog and your team averages 20 points a sprint, you are looking at roughly ten sprints to clear it. That is the kind of honest projection a stakeholder can actually plan around, instead of a date someone pulled out of the air.

The point of velocity in agile is not speed. It is predictability. A team that reliably delivers 20 points a sprint is more valuable than one that delivers 35 one sprint and 10 the next, because you can plan around the steady team and you cannot plan around the erratic one.

---

What is the difference between velocity and capacity?

These two get mixed up constantly, and the difference is the thing that keeps teams from overcommitting.

Velocity is what your team has done. It is historical. It looks backward at completed work to predict the future.

Capacity is how much your team can do right now. It is forward-looking and situational. Capacity drops when someone is on vacation, when three people are pulled onto a fire drill, or when half the team is in training all week.

You need both. Velocity gives you the baseline. Capacity adjusts it for the reality of the coming cycle. A team with a velocity of 20 but only 60% of its people available this sprint should not be committing to 20 points. Plan with velocity, then sanity-check against capacity before anyone signs up for anything.

This is where visibility matters. The teams that plan well can see their capacity, not just their velocity, because they know what every person already has on their plate across all of their projects. With that picture, you commit to a sprint knowing the team can actually deliver it.

That is the gap Workzone closes, with capacity planning and workload views that show what each person is carrying across every project, not just this one. When you can see who has room before you assign the next round, overcommitting stops being a risk. Regal Medical Group increased its project volume by 98% without adding headcount after putting that kind of visibility in place, because the work stopped stalling on people who were quietly overloaded.

See workload management in Workzone →

---

Frequently asked questions

What does velocity mean in agile?
In agile, velocity is the amount of work a team completes per sprint, measured in story points or finished tasks. The team averages it over several sprints and uses that average to decide how much work to commit to in the next one. It is a planning tool, not a performance score.

Is higher velocity always better?
No. A higher velocity is only better if it is sustainable and the work is genuinely done. Teams that chase a bigger number tend to cut corners, inflate estimates, or burn out, and the number stops meaning anything. A stable, predictable velocity is more valuable than a high one that swings wildly, because predictability is what lets you plan.

How do you improve team velocity?
Improve it by removing friction, not by pushing people harder. Clear blockers faster, reduce mid-sprint interruptions, tighten up estimates so they reflect actual effort, and make sure nobody is silently overloaded. Velocity rises on its own when the work flows cleanly. Better workload visibility usually does more for velocity than any pep talk.

What is the difference between velocity and capacity?
Velocity is what your team has done, the historical average of work completed per cycle. Capacity is what your team can do right now, which shifts with vacations, holidays, and people split across other projects. You plan with velocity for the baseline, then adjust against capacity for the cycle in front of you. Getting both right is what keeps a team from overcommitting, and it is far easier when workload is visible in one place.

How many sprints does it take to calculate velocity?
A useful average takes three to five completed cycles. One sprint tells you almost nothing, since a single good or rough week can skew it. After a handful of sprints you will have a range rather than a single number, and that range is what you plan against. Expect some natural bounce, because a team is not a machine, and the trend matters more than any single sprint.

---