Velocity Isn't Rocket Science, But People Complicate It Anyway
Velocity in Agile is just a number that tells you roughly how much work a team can handle in a sprint. That's it. You add up the story points from completed items at the end of each sprint, take an average over the last three to five sprints, and you have your velocity. Everything else is noise. Pull your sprint backlog data. Look at which user stories or features actually crossed the "done" line. Add their story point values. Do that for each sprint in your lookback window. Divide by the number of sprints. You now have an average velocity. In practice, I've seen teams spend three weeks overthinking this when they could have done it during a coffee break. Here's what most people get wrong. They treat velocity as a performance metric to compare between teams. Don't do that. Velocity is team-specific. A team with a velocity of 30 and a team with a velocity of 50 are not competing. They're different teams with different skill sets, different domain knowledge, and different ways of breaking down work. Comparing them is meaningless and toxic.
I ran into this exact problem at a previous company. Management wanted to normalize velocity across three different product teams so they could forecast a unified roadmap. The issue was that one team was working on legacy code with heavy technical debt, another was building greenfield features, and the third was maintaining production infrastructure. Their story point scales were incomparable. The workaround was simple: we stopped using story points for cross-team forecasting and switched to calendar-based capacity planning. Each team reported how many engineer-weeks they could realistically commit, and we built the roadmap from there. Took us a week to set up instead of the month we'd been going in circles.
Common Mistakes People Make
The biggest pitfall is treating velocity as fixed. It fluctuates. People go on vacation. Bugs appear. Requirements shift mid-sprint. Your velocity from last quarter doesn't guarantee your velocity next quarter. I usually recommend looking at a rolling average of the last three to five sprints and tracking the trend line. If velocity is dropping consistently, something is wrong, and the number itself won't fix it. Another mistake is including partially completed work in the velocity calculation. If a story is 90 percent done at sprint end, it doesn't count. Zero story points for incomplete items. I know some teams try to split points proportionally, but that introduces garbage into your data and makes forecasting worse, not better. Binary counting is the only approach that holds up over time. There's also the planning poker problem. If your team assigns story points inconsistently, your velocity is garbage regardless of how carefully you calculate it. One person might call something a 5, another might call the same thing a 3. This is why velocity should be recalculated periodically against actual delivery, not just derived from estimates. If your average velocity is 28 points but you consistently plan for 35, you're not calculating velocity wrong, you're just planning badly.
Get the Full Details
What Velocity Can and Cannot Tell You
Velocity tells you rate of delivery, not quality. A team can have a velocity of 60 and ship a product full of bugs. It tells you capacity, not capability. It tells you nothing about whether the team is working on the right things. You can have a perfectly calculated velocity and still be building the wrong feature for the wrong market. If your organization needs something beyond velocity for forecasting, look at throughput instead. Throughput counts completed items regardless of story point size. It's less precise for individual sprint planning but more reliable for long-term roadmapping because it's not affected by how differently teams estimate. Some teams use both metrics together. Velocity for sprint-level planning, throughput for quarterly planning. It's not flashy, but it works in practice. The honest limitation nobody likes to admit is that velocity-based forecasting breaks down for work that can't be broken into standard increments. Research spikes, proof of concepts, and exploratory work don't fit cleanly into story points. For those, you just track time spent and accept that the forecast will be fuzzy. No amount of calculation fixes that.
