• Blogs
  • >
  • Velocity in Agile: Everything You Need to Know!

Velocity in Agile: Everything You Need to Know!

     views

Velocity in Agile

What is velocity in agile – Key takeaways 

  • Velocity in agile is the amount of work getting done in a sprint. 
  • Teams commonly use story points to estimate completed work.
  • Velocity is measured at the team level, not individually.
  • A team’s velocity can change from one sprint to another.
  • Story points reflect effort, complexity, and uncertainty, not productivity.
  • There is no universally good or standard velocity number.
  • Teams use velocity to support sprint planning and project forecasting.
  • Velocity charts help teams understand delivery patterns over time.
  • Increasing velocity does not automatically mean better team performance.
  • Teams should use velocity as a planning tool, not a performance target.

Velocity in agile means the amount of work an agile team finishes during a sprint. Teams commonly measure this work by using story points. Which represent the relative effort, complexity, and uncertainty involved in completing a user story. 

Velocity is calculated at the team level rather than for individual team members. For instance – if a team completes user stories worth 25 story points in one sprint. Its velocity for that sprint is 25. 

The number can be changed from one sprint to another. A team might complete 25 points in one sprint, 30 in the next, and 22 in another. It has no relation to the team being more or less productive. 

In this blog, we will learn about velocity in agile and everything you need to know about this topic. 

To understand velocity properly, it also helps to know the agile principles that guide the team.

Velocity in agile vs. productivity

Velocity in agile tells the team how much estimated work was completed. While productivity is a broader concept that can involve efficiency, quality, and many other aspects. 

For this reason – velocity should not be used to rank individual team members or pressure a team to increase its story points.

Once a team understands its velocity. It can be used for several planning activities.

What is a good velocity in agile?

A velocity of 20 story points might be normal for one team. While another team might consistently complete 40. Story points are relative estimates, and different teams may estimate work differently.

Instead of asking whether a velocity number is high or low, teams can look for consistent and useful patterns over time. 

A relatively stable velocity can make future planning easier because the team has more historical information to work with.

How is velocity used in agile?

Teams can use velocity to:

  • Plan how much work to take into an upcoming sprint
  • Forecast how many sprints may be needed for remaining backlog items
  • Support release planning
  • Identify changes in delivery patterns
  • Understand the team’s historical delivery rate
  • Create more realistic expectations around future work

Velocity is therefore best viewed as a planning tool. And not a target that teams must continuously increase.

These uses explain why velocity is more than just a sprint metric.  

Why is velocity important in agile?

Velocity gives agile teams a way to use their past sprint performance to support future planning. 

Instead of guessing how much work the team can complete. The team can look at completed work from previous sprints and use that information when planning upcoming work.

Here are some of the main ways velocity can help an Agile team:

1. Helps with sprint planning

During sprint planning, teams can look at their recent velocity. This helps to decide how much work they may be able to take on.

For example – if a team has been completing around 25 story points per sprint. Taking on 40 points in the next sprint requires a closer look at team capacity and the work involved.

2. Supports project forecasting

Velocity can help teams estimate how long it may take to complete a particular amount of remaining work.

If the backlog has 100 story points remaining and the team’s recent average velocity is 25 points per sprint. The team needs approximately four sprints to complete that work.

3. Helps identify delivery patterns

Tracking velocity across several sprints can reveal patterns.

For example, a team’s velocity might look like:

Sprint 1 → 22 points
Sprint 2 → 24 points
Sprint 3 → 25 points
Sprint 4 → 23 points

The relatively similar numbers give the team useful historical information for planning.

On the other hand, large changes between sprints encourage the team to investigate factors such as – 

  • Changing team capacity
  • Dependencies
  • Interruptions
  • Estimation differences

4. Improves release planning

Velocity can also support release planning. If the team knows approximately how much work it has completed in previous sprints. It can use that information to estimate the number of future sprints needed for the remaining backlog.

For example:

Remaining work = 120 story points
Average velocity = 30 story points per sprint

Estimated sprints = 120 ÷ 30 = 4 sprints

The estimate should still be reviewed as the project progresses. Because the backlog and team’s circumstances may change.

5. Encourages more realistic planning

Velocity is based on what the team has actually completed rather than what it hopes to complete. This can give teams a more practical starting point when planning future work.

However, velocity should be considered alongside – 

  • Team capacity
  • Backlog changes
  • Dependencies
  • Technical complexity
  • Other project factors

It should not be used on its own to determine whether a project will meet a particular deadline.

To use velocity effectively, teams first need to know how it is calculated. 

How do you calculate velocity in agile?

Calculating velocity in Agile is relatively simple. The basic idea is to add the story points for all the user stories that the team fully completed during a sprint.

Here’s how it works.

Step 1: Choose a sprint

Start with a completed sprint. Velocity is generally calculated for a specific sprint – such as a one-week or two-week sprint.

Step 2: Identify completed user stories

Look at the stories that were fully completed by the end of the sprint.

Only work that meets the team’s definition of “done” should be included. A story that is 90% or 95% complete but still unfinished. Still, it is normally not counted toward that sprint’s velocity.

Step 3: Add the story points.

Add the story points assigned to each completed story.

For example:

User Story Story Points Status
User login 5 Done
Profile page 8 Done
Search feature 5 Done
Payment integration 8 Not Done

The team’s velocity for this sprint would be:

5 + 8 + 5 = 18 story points

The 8-point payment integration is excluded because it was not completed.

Agile velocity formula

For a single sprint, the formula is:

Sprint Velocity = Total story points completed during the sprint

When calculating average velocity across multiple sprints, use:

Average Velocity = Total story points completed across all sprints ÷ Number of sprints

A single sprint provides limited context, so teams often look at several sprints together. 

Why use multiple sprints?

A single sprint does not give an accurate picture of a team’s typical delivery rate. 

One sprint could be affected by – holidays, team members being unavailable, unexpected technical issues, or other interruptions.

Looking at several completed sprints gives the team more historical information. This can make velocity-based forecasting more useful.

What is a velocity chart in agile?

A velocity chart in agile is a visual representation of how much work a team completes. This work is across multiple sprints. It typically shows story points completed on the Y-axis and sprints on the X-axis.

Instead of looking at a list of numbers – the chart makes it easier to see how a team’s velocity changes over time.

For example, a team might have the following velocity:

Sprint Story Points Completed
Sprint 1 22
Sprint 2 27
Sprint 3 24
Sprint 4 29
Sprint 5 26

A velocity chart would plot these values across the five agile sprints.

How does a velocity chart work?

Before you start to measure your velocity in agile. It is important to know how a velocity chart works in the first place. We have briefly explained

A typical velocity chart contains:

  • X-axis: Completed sprints
  • Y-axis: Story points or another unit used to measure work
  • Bars or points: Work completed in each sprint
  • Average velocity: Sometimes shown as a reference line based on several previous sprints

For example, if a team completes 22, 27, 24, 29, and 26 story points over five sprints, its average velocity is:

(22 + 27 + 24 + 29 + 26) ÷ 5 = 25.6 story points

The team can use this historical information when planning upcoming work.

A velocity chart can help a team see whether its work is completed. And has the work been relatively consistent or has varied considerably between sprints?

For example:

Stable pattern:  24 → 26 → 25 → 27 → 26

The team has a relatively consistent delivery pattern.

Variable pattern:  15 → 30 → 18 → 32 → 20

The larger variation may encourage the team to look at factors affecting its delivery, such as – 

  • Changes in capacity
  • Dependencies
  • Interruptions
  • Estimation practices

The chart does not explain why velocity changed by itself. The team needs to discuss the context behind the numbers.

With the basic chart structure clear, we can look at how teams use it. 

Why is a velocity chart useful?

A velocity chart can help with:

  • Sprint planning: Understanding the amount of work the team has historically completed.
  • Release forecasting: Estimating how many future sprints may be required for remaining work.
  • Trend analysis: Seeing changes in completed work across sprints.
  • Team discussions: Providing a simple visual starting point for discussing delivery patterns.
  • Stakeholder communication: Helping explain Agile delivery forecasts using historical data.

However, velocity charts should be used as a planning and forecasting aid. Not as a way to compare teams or measure individual performance.

How to read a velocity chart in agile

Once you understand what a velocity chart in agile shows. The next step is learning how to interpret it. 

The goal is not simply to look for a higher number. Instead, the team can use the chart to understand its delivery pattern and make more informed plans.

Here are some ways to interpret the velocity in agile chart –

1. Look at velocity across several sprints

Start by looking at the team’s completed story points across multiple sprints rather than focusing on one sprint.

For example:

Sprint 1: 24 points
Sprint 2: 26 points
Sprint 3: 25 points
Sprint 4: 27 points

The numbers are fairly close, suggesting a relatively consistent delivery pattern.

2. Look for significant changes

A sudden increase or decrease in velocity can be a reason to investigate what changed.

For example:

28 → 27 → 15 → 26

The drop to 15 points could be related to several factors, such as:

  • A team member being unavailable
  • Unexpected technical issues
  • External dependencies
  • Production or support work
  • Changes in the team’s capacity
  • Different types of work entering the sprint

The chart shows what changed, but the team needs additional context. This is really important to understand why it changed.

3. Consider the average velocity

Teams can calculate an average from several recent sprints.

Suppose the last five sprints produced:

22, 25, 27, 24, 26 story points

The average velocity is:

(22 + 25 + 27 + 24 + 26) ÷ 5 = 24.8

The team could use approximately 25 story points per sprint as a reference when creating a forecast.

4. Don’t assume increasing velocity = better performance

A velocity chart may show numbers increasing over time. But that does not automatically mean the team has become more productive.

Velocity can change because of differences in estimation, backlog composition, team capacity, or other project circumstances.

For example – if a team changes the way it assigns story points. Its velocity may increase even though the amount of work being delivered has not changed proportionally.

5. Use the chart for forecasting

One of the most useful applications of velocity is forecasting.

Imagine a team has 100 story points remaining and its recent average velocity is 25 points per sprint.

A simple forecast would be:

100 ÷ 25 = 4 sprints

This provides a starting estimate for planning. It should be revisited as the team completes more work and as the backlog or team capacity changes.

Want to build your agile skills further?

If you work with agile teams or want to move into agile project management. An agile certification can help you build structured knowledge of – agile practices, frameworks, and delivery methods.

Explore: [PMI ACP certification / Disciplined agile leadership certification / Disciplined agile certification]

Frequently asked questions about velocity in agile

With the core concepts covered, let’s answer some common questions about agile velocity 

1. What is velocity in agile?

Velocity in agile is the amount of estimated work an agile team completes during a sprint. It is commonly measured using story points. And mainly used for planning and forecasting.

2. How do you calculate velocity in agile?

Steps to calculate velocity in agile –

  1. Add the story points of all user stories that were fully completed during a sprint. 
  2. Calculate the average velocity :

Divide the total completed story points across multiple sprints by the number of sprints.

3. What is a velocity chart in agile?

A velocity chart in agile is a visual representation of the amount of work a team completes. It usually shows sprints on the x-axis and completed story points on the y-axis.

4. What is a good velocity in agile?

There is no standard or universally good velocity. Velocity completely depends on the team and the requirements. And its estimation approach, capacity, and the type of work being completed. 

5. Is velocity the same as productivity in agile?

No. Velocity measures completed estimated work in story points. It is primarily a planning and forecasting metric. It is recommended to not be treated as a direct measure of productivity.

Related agile resources 

Previous Post

Next Post

Back To Top Button

 

 

 

 

Upcoming PMP Batches

Batch Name
Date & TimeDetails
October Batch (4 Days – Weekend) – PMP Online

03rd, 04th, 10th & 11th October 2026 Time: 8:00am to 6:00pm, ISTKnow More