A Guide to Velocity in Agile Development

Do not index

When you hear “velocity” in Agile circles, it’s easy to think of it as a speedometer. How fast can we go? How much can we possibly cram into a single sprint?

If that’s your first thought, you’ve already missed the point.

Velocity isn’t a speedometer; it’s a weather forecast. It looks at what happened yesterday to give you a pretty good, data-backed idea of what’s coming tomorrow. It’s about predictability, not raw speed.

What Is Velocity, Really?

Let’s be honest, the term ‘velocity’ gets thrown around in standups and planning meetings so often it’s almost lost all meaning. So, let’s cut through the noise.

The true purpose of velocity isn't to make your team "go faster." It's about making your delivery predictable and, most importantly, sustainable. With agile adoption skyrocketing to 86% of software teams by 2021 (a massive leap from just 37% in 2020), it's clear we need reliable ways to manage this new world of work.

That’s where velocity comes in. It’s a tool for the team, by the team.

It's a Forecast, Not a Report Card

This is the number one mistake I see leaders make: they treat velocity as a performance metric. It’s not.

Comparing velocity between two teams is like comparing apples to oranges—or maybe more like comparing a team of seasoned architects building a skyscraper to a handful of scrappy startup engineers building an MVP in a garage. Point values are relative, context is everything, and each team has its own unique fingerprint. For anyone in an agile environment, understanding the fundamentals of Scrum methodology is key to seeing how velocity fits into the bigger picture.

Think of velocity as a planning tool, plain and simple. It helps the team answer one critical question during sprint planning: "Looking at what we’ve actually finished in the past, what can we realistically commit to right now?"

This infographic nails the core idea: using past performance to find a sustainable rhythm. That's the real win.

This isn’t about pushing for short-term bursts of speed. It’s about guiding the team toward a workflow they can maintain without burning out.

When you use it right, velocity becomes a shield. It protects the team from overcommitment and builds trust with stakeholders by creating a delivery cadence they can actually count on. It stops being a weapon and starts being a tool for sanity.

How to Calculate and Track Velocity

Alright, let's get into the nitty-gritty. Calculating velocity sounds like you need a degree in data science, but it’s shockingly simple. It all boils down to story points.

But first, let’s get one thing straight, because this trips up so many teams: story points are not hours.

They’re a relative guess about effort, complexity, and all the unknowns that pop up when you start digging into the code. A "5-point" story isn't five hours of work. It’s just bigger than a "3" and smaller than an "8." If you're still fuzzy on this, our deep dive on different agile estimation methods is worth a read.

Now that we’ve cleared the air, the math is refreshingly straightforward.

The Basic Formula

At the end of a sprint, your velocity is just the sum of the story points for all user stories that are 100% done.

That’s it. No partial credit. If a 5-point story is “90% finished,” it adds exactly zero to that sprint’s velocity. It either meets your Definition of Done or it doesn’t.

This isn't about being a hard-ass; it's about keeping your data clean. That half-done story will just roll over and count toward the next sprint's velocity—once it's actually finished.

Finding a Stable Average

A single sprint’s velocity is just a snapshot in time. The real power comes from tracking this number over multiple sprints. After about three to five of them, you'll start to see a trend emerge from the noise.

By averaging the last few sprints, you get your team's baseline velocity. This isn't just a number; it's a data-backed forecast you can actually rely on.

Let’s watch this play out for a new team trying to find its rhythm.

Example in Action
A newly formed team at a Series A startup, "The Navigators," just finished their first few sprints:
Sprint 1: They completed 22 points. A solid start, but they’re still figuring out how to work together.
Sprint 2: A key developer was out sick for a week. They only managed 18 points.
Sprint 3: Things clicked. They crushed it and knocked out 25 points.
Sprint 4: They hit a gnarly, high-risk story that soaked up more time than expected, finishing with 21 points.

This example shows the natural ebb and flow of a team's output. A single sprint can be misleading, but the average tells a much more honest story.

Calculating Average Velocity Over Four Sprints

This table demonstrates how a team's velocity is calculated and averaged over several sprints to establish a reliable planning metric. Notice the initial fluctuation and eventual stabilization.

Sprint Number	Completed Story Points	Running Average Velocity
Sprint 1	22	22.0
Sprint 2	18	20.0
Sprint 3	25	21.7
Sprint 4	21	21.5

After four sprints, their average velocity is 21.5. Now, the team can go to their stakeholders and say, "We typically complete around 21 points of work per sprint."

It’s not a blood oath, but it’s a realistic forecast grounded in actual performance. And that’s infinitely more valuable than a wild guess. This average becomes their North Star for the next sprint planning session.

Using Velocity for Better Sprint Planning

Alright, your team has a number. Let's say your average velocity is 21.5. So what? You don't get a medal for that. The real power of velocity in agile development comes alive during sprint planning.

This is where you finally get to stop the vicious cycle of overcommitment and burnout. No more death marches towards an impossible deadline. No more awkward conversations explaining why, yet again, you couldn't deliver everything you promised.

Velocity isn't a command etched in stone. It’s a data-backed starting point for a conversation. If your average is 21.5, that’s your first realistic guess for the next sprint. It shifts the discussion from wishful thinking to a practical dialogue based on what your team has actually accomplished.

It’s More Than Just a Number

Of course, your team isn't a machine that spits out exactly 21.5 points every two weeks. Life happens. Your velocity is your baseline, but you absolutely have to adjust for the human element.

This is where the true art of sprint planning kicks in. You have to look at the variables.

Team Capacity: Is your lead developer taking a well-deserved week off? Is there a public holiday coming up? That 21.5 needs to be adjusted downwards.

Known Risks: Is there a story in the backlog that everyone knows is a technical minefield? You know, the one with tentacles reaching into some ancient, undocumented corner of the codebase? Acknowledge it and plan for the chaos.

Team Morale: Did the last sprint feel like a total slog? Sometimes the team just needs a slightly lighter load to recover and avoid burnout. You have to listen to them.

The goal isn’t to perfectly match your average velocity every single time. The goal is to use it as a guide to build a plan that is both ambitious and achievable. It’s about protecting your team’s well-being and building trust through predictable delivery.

How the Conversation Should Sound

Picture a planning session. The product owner is pushing to pull in 30 points to hit a massive launch date. In the past, this might have triggered a quiet sense of dread among the engineers.

Now, with velocity data, the entire conversation changes.

The scrum master can step in and say, “Hey, our average over the last four sprints is 21.5. Thirty points is a huge stretch, especially with the holiday next week. Let’s talk about what’s actually realistic.”

This reframes everything. It’s not about pushback; it’s about presenting cold, hard data. It gives the team the power to negotiate scope and commit to a workload they can actually deliver with pride.

To keep getting better, you need to reflect and adapt. Using tools like these sprint retrospective templates can help you constantly refine your process. This is what turns good teams into great ones—by creating a sustainable pace that fuels long-term success.

The Good, The Bad, and The Ugly of Velocity

Velocity is a fantastic tool. When it's used the right way, it brings a sense of calm, predictability, and rhythm to your team's work. But, like any powerful tool, you can do some serious damage with it if you don't know what you're doing.

Let's start with the good stuff. When velocity is treated as the forecasting tool it's meant to be, it’s a game-changer. It grounds conversations with stakeholders in actual data, not just wishful thinking. It also empowers your team to own their commitments and gives them a shield against the dreaded death march of an overstuffed backlog.

But all too often, this incredibly helpful metric gets twisted into something miserable.

The Bad: When Velocity Becomes a Weapon

The trouble usually starts when leadership sees the velocity number but has no clue what it actually represents. They just see a number, and their first instinct is to make it go up. This leads to a few cardinal sins in the Agile world.

Comparing Teams: A manager looks at Team A with a velocity of 20 and Team B with a velocity of 40 and instantly concludes Team B is "twice as good." This is just flat-out wrong. Story points are relative to each team’s unique context—their skills, their codebase, their definition of "done." It's like comparing someone's 40 Canadian dollars to another's 20 British pounds and completely ignoring the exchange rate.

Using It in Performance Reviews: Even worse is when velocity is weaponized against individuals. "Hey Bill, your output dropped this sprint. What's going on?" This turns a team-level forecasting tool into an instrument for micromanagement, breeding fear and absolutely wrecking psychological safety.

The Constant Push for "More": The most common trap is the relentless pressure to "increase velocity." The moment the number itself becomes the target, it stops being a useful measure of capacity. It just becomes a vanity metric that people will inevitably game.

And that pressure is where things spiral from bad to truly ugly.

The Ugly: When Gaming the System Becomes the Goal

I once worked with a startup where a new VP of Engineering declared that every team had to increase its velocity by 10% each quarter. He thought he was driving productivity. What he actually drove was chaos.

Within a couple of months, teams weren't delivering more value; they were just getting really good at hitting the number. Story point estimates started to magically inflate—what used to be a 3-point ticket was suddenly a 5. Complex features got rushed out the door, with QA getting squeezed just so the ticket could be marked "done" before the sprint review. The bug backlog exploded.

When velocity becomes a target, it ceases to be a useful measure. It becomes a proxy for success that incentivizes all the wrong behaviors: cutting corners, inflating estimates, and shipping half-baked work.

On paper, the team's velocity charts looked amazing. But the product was suffering, and morale was in the gutter. They were "moving faster," but all they were really doing was digging themselves into a deeper and deeper hole of technical debt. It’s a classic example of how chasing the wrong metrics can do more harm than good. It's a common struggle, and you can explore more strategies for how to improve team productivity without falling into these traps.

Here's the bottom line: velocity is an indicator, not an objective. Its only job is to help a team understand its own capacity so it can plan more effectively. The moment you turn it into a competition or a performance goal, you destroy its value—and you might just destroy your team's culture along with it.

Velocity Do's and Don'ts

Think of this table as your quick-reference guide. It's here to help you use velocity to empower your team and steer clear of the common traps that turn this useful metric into a destructive force.

Do	Don't
Use it for forecasting future sprints based on past performance.	Use it to compare teams. Every team's pointing scale is unique.
Track the trend over time to spot patterns and impediments.	Set "increase velocity" as a performance goal. This just encourages inflation.
Keep it team-internal. It's a tool for the team, by the team.	Use it in individual performance reviews. It's a team metric, not a personal one.
Let it facilitate conversations about capacity and commitments.	Ignore drops in velocity. A sudden change is a signal to investigate, not punish.
Keep point estimates stable. Don't change them after a sprint starts.	Measure velocity in hours. This defeats the purpose of relative estimation.

Remember, the goal isn't a higher velocity number; it's a predictable and sustainable pace of delivering real value. Keep these guardrails in mind, and you'll be on the right track.

What to Do When Velocity Goes Sideways

Okay, so your team's velocity was humming along nicely, and then suddenly it either nosedives or shoots for the moon. First rule: don't panic.

A big swing in velocity isn't a report card—it's a signal. Think of it as a flashing dashboard light telling you it's time to pull over and see what's going on under the hood.

This is your cue to get curious, not critical. It’s an opportunity to figure out what really changed, not to start pointing fingers.

Diagnosing a Velocity Drop

A sudden drop is the usual suspect, and it can be triggered by all sorts of things. Your mission is to play detective and find the root cause. A few common culprits include:

Creeping Tech Debt: The team is spending more time wrestling with clunky old code and putting out fires than they are building anything new.

Onboarding New Members: A new hire, no matter how brilliant, will temporarily slow things down as they get up to speed with the codebase, the processes, and the team's rhythm.

Vague Requirements: If the user stories are ambiguous, engineers will burn precious time just trying to figure out what they're supposed to build. Garbage in, garbage out.

Why a Sudden Spike Is Also a Red Flag

This might sound weird, but a huge, unexpected increase in velocity can be just as concerning as a drop.

If your team consistently delivers 25 points per sprint and then suddenly clocks in at 45, you should be raising an eyebrow. It might be a sign that trouble is brewing just beneath the surface.

A change in velocity in agile development is the perfect conversation starter. It's not an accusation; it's a data point that prompts the team to ask, "What changed?" and "How can we address it?"

That big number could mean the team is rushing, cutting corners on quality, or skipping key acceptance criteria just to push tickets across the "done" line. Or, hey, maybe they just mis-pointed a few stories that turned out to be way easier than expected.

Either way, it’s worth a look. The change—up or down—is the perfect topic for your next team meeting. It transforms the meeting from a routine ceremony into a real problem-solving session. To make those conversations count, check out our guide on how to run a powerful retrospective.

Beyond Velocity: Don't Lose the Forest for the Trees

Let's be honest for a second. After all this talk about calculations and charts, it's incredibly easy to get obsessed with the numbers. But we need to zoom out. Velocity in agile development is just one metric on a much larger dashboard.

Here's the hard truth: velocity measures output, not outcome.

You can have a team with a picture-perfect, stable velocity chart. They're crushing story points sprint after sprint, and everything looks great on paper. But what if they're building the wrong thing? They could be meticulously rearranging the deck chairs on the Titanic.

The goal isn't just to be busy. It's to be effective.

From Output to Outcome

Getting a handle on velocity isn't about hitting some magic number. It's about finding a sustainable rhythm so your team can stop agonizing over capacity and pour that energy into solving real customer problems. The velocity metric needs a few friends—ones that actually measure impact. Think customer satisfaction, feature adoption rates, or a drop in churn.

While a whopping 83% of organizations claim that speeding up delivery is a top priority, the real win isn't just speed—it's connecting that speed to tangible results. It's no surprise that agile-mature companies see a 237% increase in commercial performance. This proves the goal is a better business outcome, not just a higher story point count. If you're curious about the link between agile and business success, you can dive deeper into the latest agile statistics.

Velocity is a means to an end, not the end itself. Think of it as the health of your car's engine, not the destination on your GPS. You have to make sure you're actually driving somewhere your customers want to go.

Ultimately, a stable velocity is a fantastic sign of a healthy, predictable team that can ship reliably. But the real victory? Shipping something that actually matters.

Common Questions and Sticking Points

We've talked a lot about what velocity is, but let's be real—the moment you try to put this into practice, tricky questions pop up. It happens to every team.

Let's get into the weeds and answer the ones that cause the most arguments.

Should We Point Bugs and Chores?

Ah, the great debate. Do you point every little thing that eats up the team's time, or only the shiny new features?

You’ll hear strong opinions on both sides. Some teams are purists: only new, user-facing value gets points. Others argue that if it takes effort, it gets a number. The truth is, there isn't a universally "right" answer, but there's a critically right principle: be consistent.

A good middle ground for many is to point user stories and significant bugs—the ones that need real detective work—but to let routine chores slide. Whatever path you choose, stick to it religiously. The whole point of velocity is predictability, and consistency is the only way you’ll get a forecast you can actually trust.

What Is a Good Velocity?

This question is a trap. I'm serious.

There's no such thing as a "good" number. A team with a velocity of 20 isn't automatically doing worse than a team with a velocity of 50. It's like asking "what's a good number of brush strokes to finish a painting?" It's completely relative to the team's context—their experience, the complexity of their code, and how they estimate in the first place.

How Do You Handle Velocity When the Team Changes?

When someone joins or leaves, your team's entire dynamic gets a shake-up. So does its capacity. Trying to fudge the numbers or guess how to adjust your velocity is a fool's errand.

Just accept it: for the next few sprints, your velocity is going to be different. It’s not a failure; it’s a reset.

Let the new team find its groove. Track the new numbers without judgment. After a couple of sprints, a new, stable average will emerge naturally. That's your new baseline for the re-formed team.

Tired of juggling spreadsheets, Jira, and endless meetings to manage your sprints? Momentum unifies your entire agile workflow—from standups and sprint planning to triage and backlog grooming—into one seamless platform. Ditch the tool chaos and get back to shipping. Start your free beta with Momentum today.