Five completed sprints, in order: 23, 19, 31, 18, 24 points finished. That is 115 points over five sprints, so 115 divided by 5 is 23. Your sprint velocity is 23 points per sprint. The arithmetic really is that small, and any tool that makes it feel bigger than that is selling you something.
The interesting number in that list is not the 23. It is the 31.
How do you calculate sprint velocity?
Three decisions, then a division.
First, decide which sprints count. Only completed ones. The sprint currently in flight has no final figure yet, and including it drags the average toward zero on day two of every sprint.
Second, decide which stories count. Only the ones that were genuinely finished by the time the sprint ended, at their full estimated size. Not the ones in review, not the ones sitting in staging.
Third, decide your window. Sum the points from the last three to five completed sprints and divide by how many you used. That is it. You now have a rough figure for how much work your team gets through in a sprint, expressed in story points rather than hours, which is the only reason the number survives contact with reality.
Round it to a whole number while you are at it. A velocity of 22.6 implies a precision that does not exist, and a decimal point invites people to treat the figure as a measurement rather than an estimate.
What actually counts as finished
This is where most velocity numbers quietly go wrong, and it is worth being pedantic about.
A new Scrumpy board starts with seven statuses: New, Development, Testing, Code review, Stakeholder, To be released, Released. Exactly one of those means done. So a story that has been written, reviewed, tested, accepted, and is sitting in To be released waiting on Thursday's deploy scores zero for that sprint. Five of the seven columns are places where work can be very nearly finished and still count for nothing.
That feels harsh the first time you see it. It looked harsh to us. An 8-point story that is ninety percent complete has clearly consumed most of 8 points of effort, and giving it a zero seems to throw away real information about what the team did.
Here is what changed our mind: the story does not disappear. When a sprint ends, everything still open moves into the next sprint carrying its full 8 points, and it gets counted in full there once it lands. Award it 4 points now for being half done and another 8 when it finishes, and one 8-point story has contributed 12 points to your velocity. Do that across a handful of carried-over stories and your velocity inflates every sprint while your actual output stays flat. The zero is not a punishment. It is what keeps the average from double-counting.
Which brings us back to the 31.
Why one sprint always looks suspiciously good
In that opening sequence, the 18 and the 31 sit next to each other, and they are usually the same event seen twice. A chunky story runs over the end of one sprint, taking its points out of that total, then completes in the first three days of the next one and dumps the whole estimate into that total instead. The 18 was not a slow sprint and the 31 was not a heroic one. It was one late story moving across a boundary.
This is the practical reason to average several sprints rather than plan against your most recent one. A single sprint's number is mostly noise about where the boundaries happened to fall. The average is where the signal lives.
It is also the reason the spread deserves more of your attention than the mean. A team with the sequence 22, 23, 23, 24, 23 has a velocity of 23 and can plan against it with real confidence. A team with 12, 31, 18, 35, 19 also has a velocity of 23, and that number is close to fiction. Same average, completely different planning conversation. If your five sprints look like the second list, the useful question is not "what is our velocity" but "why is our sprint output swinging by a factor of three." Usually the answer is stories that are too big, or a definition of done that keeps moving.
When the number is not ready yet
Velocity needs history, and there are a few situations where it genuinely does not exist.
If you have fewer than three completed sprints, you do not have a velocity, you have an anecdote. Plan the first couple of sprints by having the team pull work until it says stop, and let the number arrive on its own. Once you have three or four sprints, an honest figure appears whether you like it or not.
If you changed your sprint length, the old sprints are no longer comparable. Two weeks of work and three weeks of work are different sized containers, and averaging them gives you a number that describes neither. This is one of the better arguments for picking a sprint length and leaving it alone.
And if half the team is new, or you just moved onto an unfamiliar part of the codebase, treat the old average as a loose upper bound rather than a forecast. Velocity describes the team that produced it.
The limit worth stating plainly
Velocity is a planning input. It is not a productivity metric, it is not a KPI, and it is not something to put on a slide next to another team's number.
Two reasons, and the second one is the serious one.
Points are local. Your team's 5 and another team's 5 were calibrated against different reference stories in different codebases by different people. Comparing the resulting velocities is like comparing two temperatures when nobody agreed on the scale.
And the moment velocity becomes a target, it stops measuring anything. A team asked to raise its velocity has an obvious, painless move available: estimate more generously. Nothing about the work changes, the numbers go up, everyone reports progress, and the one figure you were using to keep sprint plans honest is now the figure with the most pressure on it. You have not made the team faster. You have made your planning data unreliable and taught everyone that the safe answer to "how big is this" is "bigger than I think."
The 2020 Scrum Guide, worth noting, never uses the word velocity at all. What it says is that "the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts." That is the whole job description. Past performance, so the team can forecast. Nothing about measurement, nothing about improvement targets.
What to actually do with it
Velocity earns its keep in exactly one moment: the point in sprint planning where the team has pulled in stories and someone has to decide whether that is a plan or a wish. You total the committed points, you compare them to the average, and if the commitment is meaningfully above what the team has ever finished, you take something out. That is the whole function. A number that lets one person say "that is more than we have ever done in two weeks" without it becoming an argument about who is being pessimistic.
It pairs naturally with a burn-up chart during the sprint. Velocity tells you what to commit to on Monday of week one, the chart tells you whether the commitment is holding up by Wednesday of week two.
In Scrumpy the number is computed for you, and where it appears reflects the difference above. Sprint planning and the backlog show a rolling average of the last five completed sprints, because that is what you plan against. The dashboard shows the all-time figure, because that is the longer trend. Committed points sit next to it as a small bar that turns amber when you match your average and red once you are more than ten percent past it. We render it as "18 / ~23", with the tilde, and the tilde is deliberate. It is a reminder in the interface itself that the right-hand number is an estimate of your own past, not a quota someone set.
If your team has never finished a sprint, you get a dash rather than an invented zero. Finish three, and it will tell you something worth knowing. Then use it the way you would use a weather forecast: to decide what to pack, not to grade the sky. If you want to see what yours looks like, start a board and run one sprint properly, and the number will find you.
Frequently asked questions
How do you calculate sprint velocity?
Add up the story points of the stories your team actually finished in each completed sprint, then divide by the number of sprints. If the last five sprints delivered 23, 19, 31, 18 and 24 points, that is 115 points over five sprints, so the velocity is 23. Only fully finished work counts, and only completed sprints go into the average.
How many sprints should you average for velocity?
Three to five recent sprints is the usual window. Fewer than three and one unusual sprint dominates the number; many more than five and you are averaging in a team that no longer exists, with different people and a different codebase. A rolling window of the last five completed sprints is a good default.
Do unfinished stories count toward velocity?
No. A story that is not finished when the sprint ends scores zero, no matter how close it was. There is no partial credit, because the story keeps its full point value when it rolls into the next sprint and gets counted there. Half-crediting it in both sprints would count the same work twice.
Is sprint velocity a good measure of team performance?
No. Velocity is a planning input, not a performance metric. Story points are a team's own private unit, so velocity cannot be compared between teams, and the moment it becomes a target the team can raise it by estimating more generously without delivering anything extra. Use it to sanity-check a sprint commitment, not to grade anyone.
