What Is Velocity In Agile? Formula, Examples, And Common

In Agile project management, velocity is an important metric teams must calculate to clearly identify how much work they can actually complete in a sprint. So, how can velocity in Agile help teams plan their work better? This article is where you can find the answer. 

In this article, you’ll take a closer look at the following things:

• What is velocity in Agile?
• Importance of Agile velocity
• How to calculate Agile velocity, plus examples
• How Agile teams use velocity in planning
• Main differences between velocity, capacity, and productivity in Agile
• Factors affecting Agile velocity
• Common mistakes when using Agile velocity
• How to improve Agile velocity

Keep reading, and you’ll discover the basics of Agile velocity. 

What Is Velocity In Agile?

Velocity in Agile is a measure of how much work a team can actually complete during a single iteration (usually a sprint). It’s often calculated based on story points, which represent the effort or complexity of tasks, rather than exact hours. In other words, it helps teams answer the question: *“How much can we actually get done?”

To make this clearer, let’s take this example:

Imagine a team working in two-week sprints. In their first sprint, they complete tasks worth 20 story points. In the next one, they finish 25, and then maybe 22. After a few cycles, their average velocity settles around, say, 22 story points per sprint. 

So when planning the next sprint, they won’t just guess, they’ll likely commit to around that number to ensure their workflows run smoothly without burnout. For this reason, the team has a more grounded way to plan instead of overpromising or under-delivering.

Why Agile Velocity Matters

Agile velocity looks simple, yet it plays a crucial role in keeping work realistic and manageable. Below are the visible benefits of Agile velocity:

Velocity helps teams estimate how long a project might take based on real performance, not assumptions. By looking at past sprints, teams can predict how many iterations are needed to complete their remaining work. Of course, numbers aren’t completely accurate, but they give a much more reliable timeline than vague estimates.

Instead of overloading a sprint with too many tasks, teams use velocity to set a realistic limit. If a team’s average velocity is around 25 story points, committing to 40 would probably be optimistic at best. This helps prevent burnout and keeps the pace sustainable over time.

Over several sprints, velocity becomes a reliable reference point for planning future work. Teams accordingly start to understand their capacity better, which leads to more consistent delivery. And, more importantly, it builds trust with stakeholders because commitments are based on actual data, not just best guesses.

How To Calculate Agile Velocity (Formula + Examples)

So, how can your team calculate Agile velocity? Below is the basic formula and a few practical rules, plus examples, to help you calculate Agile velocity effectively: 

Agile Velocity Formula

At its simplest, Agile velocity is calculated using this formula:

Velocity = Total Story Points Completed / Number of Sprints

Here’s how Agile teams typically gather numbers and calculate Agile velocity:

1. Choose recent sprints: Select a few completed sprints (usually the last 3 to 5)
2. Add up completed story points: For each sprint, count only the story points tied to tasks that are fully completed. Not “almost done,” not “in review,” but only work that meets the team’s definition of done (DoD).
3. Calculate the average: Once you have the total, divide it by the number of sprints you included. That result is your team’s average velocity.

When calculating Agile velocity, you should remember a few important rules as follows:

• Only count fully completed work: If a task is unfinished, it doesn’t count. This keeps the metric honest.

• Velocity is team-specific: You really shouldn’t compare velocity across teams. Different teams estimate story points differently, so comparisons can be misleading.

• Consistency matters more than spikes: One unusually high or low sprint doesn’t define your velocity. What you’re looking for is a stable trend over time.

Example Of Agile Velocity Calculation

Now, let’s take an example to better understand how Agile velocity is calculated in real projects:

Imagine your team has completed four sprints with the following results:

Now divide that sum of completed story points by 4 sprints: 85 ÷ 4 = 21.25

In practice, teams might round that number or treat it as a range (say, 20–22). So, your average velocity is roughly 21 story points per sprint. This means your team can plan work that equals the effort and complexity of about 21 story points per sprint.

How Agile Teams Use Velocity In Planning

So, once you’ve calculated velocity, what do you actually do with it? This is where Agile velocity starts to become useful as a practical planning tool that helps teams make smarter, more realistic decisions about upcoming work. Here’s how Agile teams can use it in planning:

Teams use velocity to decide how much work to pull into the next sprint. If the average velocity is around 21 story points, committing to something close to that number helps avoid overloading the team. It’s not a strict limit, but it keeps expectations realistic.

Velocity also helps estimate how long it might take to complete a larger set of features or an entire project. By dividing the total backlog size by the team’s average velocity, teams can get a rough idea of how many sprints are needed. 

Velocity can also reveal patterns over time. Is the team becoming more consistent? Are there sudden drops or spikes? These trends can signal underlying issues, like bottlenecks, changing team capacity, or even improvements in workflow. 

So, velocity doesn’t just help teams plan forward. When looking further, teams can adopt it to reflect their workflows and adjust along the way.

Velocity Vs Capacity Vs Productivity In Agile

In Agile project management, teams often mix up these three terms: velocity, capacity, and productivity. These terms are somehow related, but they’re not interchangeable and serve different purposes accordingly. Understanding the differences between them and how they connect helps teams use them better to improve workflows.

Velocity Vs Capacity

Velocity is the (average) amount of work a team actually completed in past sprints (measured in story points). Meanwhile, capacity is the number of work hours a team can have for an upcoming sprint, based on available time and resources (like team size, working days, etc.).

They both help with planning. But one is based on past performance, while the other is more about current availability. 

The comparison table will help you better understand the key differences between these terms:

In practice, many Agile teams don’t use velocity and capacity separately but combine them to create more realistic sprint commitments.

A common approach is to start with historical velocity (what the team has consistently delivered) and then adjust it based on current capacity (who’s available this sprint) to calculate the target velocity. The following formula tells it all:

Target Velocity = Average Velocity x (Current Capacity / Historical Capacity)

For example, if your team’s average velocity is 25 story points but capacity drops to 80% due to vacations or meetings, a more realistic target would be around 20 story points.

Velocity Vs Productivity

Many often consider velocity as a metric to measure a team’s productivity. But in fact, they serve different purposes. Velocity measures how much work is completed (in story points), while productivity refers to how efficiently a team turns effort into valuable output.

The comparison table tells you clearly how different they are:

With those differences, we clearly see that high velocity doesn’t mean high productivity. A team may have high velocity but low productivity if they complete many story points that don’t deliver real value (e.g., unnecessary features or rework). Conversely, a team could show lower velocity but high productivity if they focus on fewer, high-impact tasks that truly matter.

So, velocity is useful, but it shouldn’t be used as a performance metric. It tells you *how much* work gets done, but not how well or how valuable that work is.

What Affects Agile Velocity

Agile velocity can be influenced by several factors. Looking at what affects this metric, Agile teams can evaluate velocity correctly and see whether every fluctuation means something wrong:

Changes in team size can directly affect velocity. Adding more members might either increase or reduce capacity (mainly because new people need time to onboard and sync with the team). Meanwhile, if key members leave or are unavailable, velocity can drop quickly. 

So, when velocity drops from 22 to 18 story points, it doesn’t mean the team is performing worse. It might simply reflect changes in team availability or the time needed for new members to get up to speed.

Not all work has the same level of complexity. A sprint filled with highly complex or uncertain tasks will likely result in lower velocity, even if the team is working just as hard. 

Accumulated technical debt can slow teams down over time. Instead of focusing purely on new features, teams may need to spend effort fixing bugs, refactoring code, or dealing with fragile systems. This “hidden work” often reduces the number of story points completed.

The final factor is unplanned work or events interrupting workflows and hence indirectly reducing the number of work items completely done. These interruptions may involve urgent bug fixes, production issues, or unexpected meetings. They eat up the team’s available time, making it harder to complete planned tasks and maintain consistent velocity.

Common Mistakes When Using Velocity In Agile

Velocity is useful, but it’s easy to misuse. And that misuse can lead teams in the wrong direction, even when the numbers look “good” on paper. So, you should learn about the common mistakes that teams often make when using velocity in Agile, the reasons behind, and how to avoid.

Comparing Velocity Across Teams

Comparing velocity across teams isn’t seemingly something wrong. You may think that if Team A delivers 40 story points per sprint and Team B delivers 25, Team A must be more productive. But it’s not really correct. 

When diving deep, you’ll soon realize that this cross-team comparison itself is a problem. Story points (a measurement unit of Agile velocity) are relative, not standardized. Each team estimates work differently based on their own understanding, experience, and context. Not to mention that their team size, work complexity, and interruptions are different, leading to different velocity numbers. 

So one team’s “5 points” might be another team’s “8” or even “3.” That makes direct comparisons unreliable and even misleading.

For example, imagine two teams working on similar features. Team A reports a velocity of 40, while Team B reports 25. But Team A uses broader estimates (larger point values), while Team B breaks work into smaller, more detailed tasks. In reality, both teams might be delivering at a similar pace, but they just measure their work completion differently.

How to overcome this mistake:

Instead of relying on raw velocity numbers, teams should:

• Look at whether each individual team’s velocity is stable or improving over time, as consistency matters more than size.
• Compare planned and completed work (often called the “say-do” ratio) to see how predictable a team is.
• Evaluate outcomes teams deliver (e.g., features released, customer impact, and quality improvements) instead of just velocity numbers.

Turning Velocity Into A Performance Target

One common mistake is seeing velocity as a performance goal. This implicitly encourages teams to improve their velocity numbers, which they misinterpret as a signal of significant progress. 

But the scenes behind may not show that. Teams may prioritize easier tasks or break down work into unnecessarily smaller tasks just to complete more points. In some cases, considering velocity a performance target can decrease quality because teams focus on hitting a number instead of delivering true value.

How to overcome this mistake:

• Use velocity as a planning tool to measure output, not a goal for performance improvements.
• Track metrics like customer satisfaction, feature adoption, or business impact to measure performance.
• Encourage teams to adopt a stable, predictable velocity rather than a constantly increasing one.
• Support team improvement qualitatively by using retrospectives to identify bottlenecks, communication gaps, or workflow issues.

Ignoring Quality And Business Value

Many Agile teams also focus on how much work gets done while overlooking what kind of work is being delivered. This means they might hit high velocity numbers, but the output is full of bugs or doesn’t meet user needs.

Velocity doesn’t inherently account for quality or impact. So if teams ignore quality and business value when calculating it, they risk optimizing for the wrong thing.

How to overcome this mistake:

• Combine velocity with quality metrics (e.g., defect rates, rework, or test coverage) to ensure standards are maintained.
• Prioritize high-value work in the backlog to focus on features that deliver real user or business impact.
• Incorporate feedback loops (like regular reviews and user feedback) to validate whether delivered work actually matters.

How To Improve Agile Velocity

Improving Agile velocity here doesn’t mean constantly increasing the number itself. Instead, teams should focus on improving how work gets done by making processes smoother, reducing inefficiencies, and removing common blockers. When those things improve, velocity tends to follow naturally. 

Below are some practical ways to do that:

Large, vague tasks will slow everything down. By breaking down user stories into smaller, more manageable pieces, teams can complete work more consistently within a sprint. 

Handling technical debt (e.g., through regular refactoring or code cleanup) keeps the system maintainable. But spending too much time on this act can reduce the number of completed work items. Meanwhile, ignoring technical debt may improve velocity in the short term, but it usually backfires later. 

So, instead of ignoring technical debt completely, try to reduce it wisely by allocating time (e.g., 20%) for debt reduction in every sprint, treating the debt as a backlog item, and prioritizing the code portions that cause the most bugs. 

• Improve team collaboration

Communication gaps can quietly eat up time. When teams collaborate well, they resolve issues faster and avoid unnecessary delays. But improving team collaboration here doesn’t mean holding as many meetings as possible but focuses on how teams communicate and work in sync.

• Maintain consistent estimation

Velocity becomes meaningful only when estimation is consistent. If story points are assigned randomly or change significantly from sprint to sprint, velocity loses its value as a planning tool. Use shared understanding and reference points, and teams can keep estimates stable.

FAQs About Velocity In Agile

What Is The Velocity Of A Sprint?

The velocity of a sprint is simply the total amount of work a team completes during that specific sprint, usually measured in story points. It only includes tasks that are fully finished, and anything incomplete doesn’t count, even if it’s 90% done.

What Is The Difference Between Burndown And Velocity?

Velocity and burndown charts serve different purposes. Accordingly, velocity shows how much work a team completes per sprint (a measure of output over time). Meanwhile, burndown charts focus on how much work remains within a sprint or release (a measure of progress toward completion). In real projects, teams often use both together by using velocity for planning and burndown for day-to-day tracking.

What Is Good Velocity In Scrum?

A good velocity doesn’t refer to exact numbers, but a consistent and sustainable measure of completed work for a specific team over time. For example, if a team consistently delivers around 20 or even 40 story points per sprint, that’s a good velocity for them. This consistency ensures reliable forecasting. 

Why Does Velocity Change From Sprint To Sprint?

Velocity changes over sprints due to various factors. Changes in team size, task complexity, technical challenges, or even unexpected interruptions can all affect how much work gets completed. Velocity variation isn’t something bad. Instead of just looking at velocity numbers and small sprint-to-sprint changes, teams should observe overall trends. 

Is Higher Velocity Always Better In Agile?

Not really, and this is where people often get it wrong. A higher velocity doesn’t always mean better performance. More particularly, when teams complete more work items, it doesn’t mean they work better.

Teams can increase velocity by inflating estimates, rushing work, or prioritizing easier tasks. But that doesn’t guarantee higher quality or better outcomes. In some cases, it can actually lead to more bugs or rework later.

So, instead of chasing higher numbers, teams should aim for steady, reliable velocity. This helps reflect real progress and deliver meaningful value.

Conclusion

Velocity is a crucial metric that every team should learn when adopting Agile approaches. It measures how much work a team can complete in a sprint, usually based on story points, and helps teams plan with more confidence over time. When used correctly, it becomes a reliable tool for future planning. 

So now, if you’re looking for a trusted, experienced partner to manage your Agile projects, why don’t you work with Designveloper. 

As a leading software development and IT consultation company in Vietnam, we’ve applied Agile approaches like Scrum and Kanban to build high-quality, scalable SaaS platforms, web apps, and mobile apps. Our teams combine Agile with professional techniques (like pair programming and continuous feedback loops) and powerful project management tools (like Jira and Trello). Our goal is to keep development fast while maintaining good code quality.

With our mastery in 50+ modern technologies, including artificial intelligence, we help various clients across domains build digital solutions that deliver real value to end users (e.g., increasing customer satisfaction or streamlining workflows). Some of our successful projects include Lumin, Swell & Switchboard, Song Nhi, ODC, and HANOI ON. 

Whether you’re looking to develop from scratch or modernize an existing system, Designveloper is willing to help you achieve that goal. Contact us and let’s turn your ideas into real products!