Sprint velocity is the total number of story points your team completes in a single sprint. To calculate it, add up the story points for every user story that met your team’s Definition of Done by the end of the sprint. Partially finished stories don’t count. Once you have velocity figures for several sprints, average them to get a reliable number you can use for planning future work.
The Basic Calculation
At the end of each sprint, look at every user story the team finished. “Finished” means it fully meets your Definition of Done, not that it’s 90% complete or in code review. Sum the story points assigned to those completed stories, and that total is your velocity for that sprint.
Say your team committed to five user stories estimated at 3, 5, 8, 5, and 2 story points. If the team completed four of them but the 8-point story didn’t meet the Definition of Done, your velocity for that sprint is 15 (3 + 5 + 5 + 2), not 23. The unfinished story moves to a future sprint and gets re-evaluated based on whatever work remains.
A single sprint’s velocity isn’t very useful on its own. You need data from at least three to five sprints before the number becomes a meaningful planning tool. To get your average velocity, add the velocity from each sprint and divide by the number of sprints:
Average Velocity = Total Story Points Completed Across All Sprints ÷ Number of Sprints
If your team completed 28, 32, and 30 story points over three sprints, your average velocity is 30. That number becomes the baseline for estimating how much work the team can realistically take on in the next sprint and how many sprints a larger body of work will require.
Why Partial Credit Doesn’t Count
It’s tempting to give a story “most of its points” when it’s nearly done, but velocity specifically measures completed work. Awarding partial credit undermines the metric’s purpose, which is to give you a reliable, repeatable number for forecasting. If you start mixing in half-finished work, your velocity becomes inflated and your sprint commitments start falling apart. A story that’s 90% done still has unknown work left, and that uncertainty is exactly what you’re trying to keep out of the calculation.
When a story doesn’t finish, move it to the next sprint and reassess its remaining effort. If the team already completed most of the work, the leftover piece may deserve a smaller point estimate. That smaller estimate will then count toward velocity in the sprint where it actually gets done.
Adjusting for Holidays and Time Off
Your average velocity assumes a “normal” sprint where the full team is available for the usual number of working days. When a sprint includes holidays or significant PTO, you’ll want to adjust your forecast so you don’t overcommit. A straightforward formula for this:
Predicted Velocity = Average Velocity × (Planned Working Days ÷ Average Working Days)
If your average velocity is 30 story points across sprints that typically have 10 working days, but the upcoming sprint only has 8 working days due to holidays, your predicted velocity is 30 × (8 ÷ 10) = 24 story points. This gives you a realistic target rather than loading the sprint with work the team can’t finish.
The same logic applies when a team member is on vacation. If you have a five-person team and one person is out for the entire sprint, you’ve lost roughly 20% of your capacity. Scale the predicted velocity down accordingly. These adjustments don’t need to be precise to the decimal. The goal is a reasonable expectation, not a perfect prediction.
Velocity vs. Capacity
These two terms show up in most agile planning tools and are easy to confuse. Capacity is the maximum number of story points or hours your team can handle in a single sprint. Think of it as the size of the container. Velocity is your team’s average capacity over time, based on what they’ve actually delivered. A team might have a capacity of 35 story points per sprint on paper, but if they consistently deliver 30, their velocity is 30.
When you’re planning a larger effort like an epic estimated at 35 story points, velocity tells you how many sprints to budget. A team with a velocity of 30 would need two sprints to complete that epic, assuming no other work competes for the same capacity. Both numbers work together to keep your roadmap grounded in reality rather than optimism.
Using Velocity for Sprint Planning
Once you have a stable average velocity, sprint planning becomes more straightforward. Pull items from your backlog in priority order and add up their story point estimates until you approach your average velocity. If your velocity is 30, don’t load 45 points into the sprint hoping the team will stretch. Consistently overloading sprints leads to carryover, which makes your velocity data noisier and your forecasts less reliable.
For longer-term planning, divide the total story points in your backlog (or in a release) by your average velocity to estimate the number of sprints needed. A release with 120 estimated story points and a team velocity of 30 means roughly four sprints of work. Add a buffer for the unknowns that always surface, and you have a realistic timeline to share with stakeholders.
What Velocity Should Not Be Used For
Velocity is a planning tool for one team. It is not a performance score, and it should never be used to compare teams against each other. Story points are relative estimates, and every team calibrates them differently. A team that calls something 5 points might be doing similar work to a team that calls it 8. The number of developers on a team, the complexity of their domain, and even their estimation style all affect the raw number. Comparing velocity across teams is like comparing shoe sizes to decide who runs faster.
Using velocity as a productivity target also creates perverse incentives. Teams will inflate their estimates to hit a number rather than focusing on delivering valuable software. Velocity works best when it’s treated as a diagnostic tool that the team owns, helping them understand their own rhythm and plan work they can actually finish. If velocity trends downward over several sprints, that’s a signal worth discussing in a retrospective. If it holds steady, the team has a dependable baseline for planning. Either way, the number belongs to the team, not to management scorecards.
Tracking Velocity Over Time
Most agile project management tools generate a velocity chart automatically, plotting completed story points per sprint on a bar graph with a running average line. If you’re working with simpler tools, a basic spreadsheet works fine. Record the sprint number, the story points committed, and the story points completed. Chart the completed column over time.
Look for the trend, not individual data points. A single low sprint might mean someone was sick or the team tackled an unusually complex story. What matters is the pattern across five, ten, or fifteen sprints. A stable trend line means your estimates and planning are consistent. A volatile line, where velocity swings wildly from sprint to sprint, usually points to estimation problems, scope changes mid-sprint, or unclear definitions of done. Addressing those root causes will do more for your planning accuracy than any formula adjustment.