How Do You Figure Out Velocity

Velocity in Agile Teams

Velocity is simply the average number of story points a team completes per iteration. That's the textbook definition. The actual practice of figuring it out is a lot messier than that sentence suggests. Most teams I've worked with spent their first few sprints completely misunderstanding what they were measuring because nobody bothered to explain why the numbers looked so useless.

The basic method is straightforward. At the end of each sprint, tally up the story points from all completed items. Do this for at least three sprints, then average them. That average is your velocity. But here's where people go wrong: they treat that average as a prediction tool rather than a planning baseline, and then they wonder why their roadmap looks like a fantasy novel. Start by making sure your team actually agrees on what a story point represents. This sounds obvious but I've seen multiple teams calculate "velocity" while two of their developers were using fundamentally different scales for estimation. One developer thought a 5-point story was "moderately complex with some uncertainty" and another thought it meant "we probably need to rewrite half the database." Your velocity numbers are garbage if your estimation framework isn't aligned. Use the Fibonacci scale or a simple 1-2-3-5-8 system. Don't use linear numbers like 1-2-3-4-5-6-7-8-9-10. Linear scales give a false sense of precision. Nobody can distinguish a 7 from an 8 in any meaningful way. The gaps in Fibonacci forces harder conversations during planning, which is exactly what you want before you commit to work.

Only count fully completed work. Half-finished features don't count. A login page that works but doesn't handle error states doesn't count. If it's not shippable, it's zero velocity. This rule is non-negotiable if you want your numbers to mean anything over time. I learned this the hard way during a migration project where we had about twelve sprints of data. Our velocity was bouncing between 28 and 34 points, which looked fine on paper. Then we tried to use it to forecast a release date and came up with something like six months when the actual work took fourteen. The problem was a subset of our team had been logging "completed" items that required significant QA follow-up that wasn't tracked in the same sprint. Those items counted toward velocity but consumed capacity in the next sprint that nobody accounted for. The workaround was implementing a strict definition of done that included testing sign-off before a story could be moved to closed. It dropped our velocity by about 20% overnight because we'd been inflating it, but suddenly the forecast became accurate within a 10% margin. Another thing people miss is that velocity is team-specific, not person-specific. If you try to derive individual contribution from velocity, you'll get wrong answers every time. Two developers might complete the same number of points in a sprint, but one was unblocking others and handling infrastructure work that didn't have its own story tickets. Velocity measures the team's output capacity, nothing more.

When Velocity Stops Working

There are legitimate scenarios where velocity becomes unreliable or actively misleading. New team members entering mid-sprint will skew your average. I'd recommend not including the affected sprint in your velocity calculation and instead waiting for two full sprints of the restructured team before recalculating. Similarly, if your team takes a month off for holidays or there's a major business disruption, exclude that sprint entirely. Averaging in anomalous data points creates false expectations. Changing scope between sprints also breaks velocity comparisons. If sprint 4 had ten straightforward bug fixes and sprint 5 had five complex feature implementations, both might show 21 points completed, but they represent very different levels of effort and risk. Don't treat identical point totals as interchangeable. The trend line across sprints matters more than any single data point. Watch whether velocity is going up, down, or staying flat over a rolling four-sprint window, not whether this sprint's number is higher than last sprint's number. If your team is under twenty sprints old, don't rely on velocity for forecasting at all. Use range-based estimates instead. Say "we expect to complete between 20 and 32 points next sprint" based on whatever partial data you have. A single average number gives a false impression of confidence that you don't actually possess yet. By around sprint fifteen or so, your velocity stabilizes enough to be useful for medium-term planning, but even then it should always be presented as a range, not a fixed number.

Some organizations try to compare velocity across teams. Don't do it. Team A completing 40 points per sprint and Team B completing 25 points per sprint tells you absolutely nothing about relative productivity. Story points are relative within a team, not absolute across teams. One team's 5-point story might be another team's 2-point story depending on their expertise, tooling, and domain familiarity. Any leadership that asks you to normalize velocity across teams is asking a question that has no valid answer. The practical takeaway is that velocity is a planning instrument, not a performance metric. When teams treat it as a score to beat, the numbers become dishonest. When they treat it as a signal about their own capacity, it becomes one of the most useful tools in agile project management. Calculate it honestly, track the trend, and adjust your planning around the data you actually have instead of the data you wish you had.