Velocity Range

Close

Forecasting with a Velocity Range

A velocity range gives teams and stakeholders a more honest way to forecast than a single average velocity.

Instead of saying, “This team will complete 33 points per sprint,” a team might say, “Based on recent history, this team is likely to complete between 27 and 36 points per sprint.”

That range can then be used to forecast how much work may be delivered by a fixed date or when a fixed scope might be completed.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need to forecast a milestone using story point estimates and historical velocity data.

It is especially useful when:

  • Stakeholders are asking for one date or one number
  • The team has enough recent sprint data to see a pattern
  • Average velocity is making the forecast look more certain than it is
  • A fixed-date or fixed-scope forecast needs a realistic velocity input
  • Leaders need to understand why a range is more useful than false precision

What This Page Covers

This page explains how to:

  • Understand why average velocity is not enough
  • Create a low-to-high velocity range from recent sprint data
  • Use that range in fixed-date and fixed-scope forecasts
  • Handle unusual sprint velocities
  • Communicate the range to stakeholders without turning it into a commitment

If you need the broader forecasting model first, start with The Components of an Agile Forecast.

Why Average Velocity Is Not Enough

Many teams forecast using average velocity.

That is understandable. Average velocity is easy to calculate, easy to explain, and often feels more precise than a range. If a team’s past velocities average 33 points per sprint, it is tempting to forecast future sprints at exactly 33 points each.

The problem is that the average is probably wrong for any specific future sprint.

A simple analogy helps. Suppose you look at your last ten lunches and calculate that you spent an average of $11.43. If someone asks what lunch will cost three months from today, $11.43 is a logical answer. It is also very likely wrong.

You may never have spent exactly $11.43 on lunch. Some lunches cost less. Some cost more. A range such as $10 to $25 may be less precise, but it is more likely to be accurate.

Velocity works the same way.

A team may average 33 points per sprint, but that does not mean it will complete exactly 33 points in the next sprint. It definitely does not mean the team will complete exactly 33 points in every sprint over a longer milestone plan.

A velocity range gives a more honest forecast.

Precision Is Not the Same as Accuracy

Precise estimates feel good.

Saying, “We will deliver 165 points over the next five sprints,” sounds more confident than saying, “We are likely to deliver between 135 and 180 points.”

But confidence is not the same as usefulness.

A precise forecast that is likely to be wrong is not better than a range that honestly reflects uncertainty. Stakeholders do not need false precision. They need enough information to make responsible tradeoff decisions.

A range helps them see:

  • How much work is likely to fit
  • How much uncertainty exists
  • What happens if velocity comes in near the low end
  • What happens if velocity comes in near the high end
  • Whether scope needs to change to make a date more likely

[!NOTE]

[Insert visual: Average Velocity vs. Velocity Range]

What It Should Look Like: A simple side-by-side comparison. On the left, show Average Velocity as a single point or single vertical marker labeled something like “33 points.” On the right, show Velocity Range as a horizontal low-to-high band labeled something like “27–36 points.” The design should make the contrast obvious: the average looks precise but narrow; the range shows realistic variation. Keep it clean and instructional, not chart-heavy. This could be a small card-style graphic with two columns, light labels, and a short takeaway line such as “A range is less precise, but often more accurate.”

Caption: A single average velocity can make a forecast look more precise than the evidence supports, while a velocity range shows likely variation.

Alt text: Comparison of average velocity and velocity range, showing a single average point versus a low-to-high range of likely sprint velocities.

The goal is not to make the forecast look scientific. The goal is to make it useful.

What a Velocity Range Is

A velocity range is a low-to-high forecast of how much work a team is likely to complete per sprint.

For example:

Based on recent history, this team is likely to complete between 27 and 36 points per sprint.

That does not mean the team guarantees at least 27 points or promises as many as 36. It means recent evidence suggests the team’s future velocity is likely to fall somewhere in that range.

The range can then be multiplied by the number of sprints in a plan.

If five sprints remain and the team’s velocity range is 27 to 36 points, the milestone forecast is roughly:

  • Low end: 5 × 27 = 135 points
  • High end: 5 × 36 = 180 points

The team can now compare 135 to 180 points with the ordered product backlog and have a better conversation about likely outcomes, risk, and tradeoffs.

[!NOTE]

[Insert visual: Velocity Range Forecast Formula]

Use one of our slide graphics of a product backlog with arrows pointing into it at 5x27 and 5x36.

Caption: Multiplying the number of remaining sprints by the low and high ends of the velocity range creates a realistic forecast range.

Alt text: Velocity range forecast formula showing 5 sprints multiplied by 27 to 36 points per sprint, resulting in a forecast range of 135 to 180 points.

Use Recent Data, Not Ancient History

A velocity range should be based on recent, relevant history.

You do not need years of velocity data. In fact, old data can make the forecast worse if the team, product, technology, or way of working has changed.

Look back far enough to see a realistic pattern, but not so far that the data no longer describes the current team. Your team’s velocity when disco ruled the airwaves is irrelevant.

For many teams, three to six months of completed sprints is enough. Looking back as far as a year may be reasonable if the team has been stable and the work is similar. Going further back is usually not helpful.

Use data from the team that will do the work. Do not borrow another team’s velocity.

Two Simple Ways to Create a Velocity Range

There are more sophisticated statistical approaches to forecasting velocity. Some can be useful. But in most planning conversations, the best method is one the team and stakeholders can understand.

Here are two simple approaches.

Option 1: Use Judgment from Recent Data

Start by listing the team’s recent sprint velocities.

Then choose a realistic low and high value based on the pattern in the data. This works better than it may sound because most teams are not looking at hundreds of data points. They may be looking at 8, 12, or 15 recent sprints.

With that amount of data, the team can often see a reasonable range.

For example, if recent velocities cluster mostly between 28 and 36 points, with a median around 33, a range of 28 to 36 may be reasonable.

This approach has an important advantage: stakeholders can see the data. They may argue for a slightly different range, but they cannot reasonably claim the team’s likely future velocity is 45 to 55 if the recent data does not support it.

Option 2: Trim the Highs and Lows

A second simple approach is to remove the highest and lowest values until five or six values remain.

Here is the process:

  1. List the team’s recent sprint velocities.
  2. Sort the values from low to high.
  3. Remove the lowest and highest value.
  4. Repeat until five or six values remain.
  5. Use the lowest and highest remaining values as the velocity range.

This removes unusual highs and lows while keeping the range grounded in actual team data.

For example, if a team has 11 sprint velocities, sort them, remove the highest and lowest, then remove the next highest and lowest, and continue until five or six values remain. The low and high of the remaining values become the range.

This approach is simple, transparent, and easier to defend than a black-box calculation.

Use the Velocity Range Calculator

Mountain Goat Software’s Velocity Range Calculator can help teams create a forecast from historical velocity values.

Enter the team’s past velocity values and the number of planned sprints. The tool forecasts a likely future velocity range and the amount of work the team can expect to complete over that number of sprints.

The tool is especially useful when stakeholders are used to seeing one average velocity and need help seeing why a range is more useful.

Using a Velocity Range in a Fixed-Date Plan

A fixed-date plan starts with a date that cannot easily move.

The planning question is:

How much can we deliver by this date?

To forecast with a velocity range, multiply the number of remaining sprints by the low and high ends of the range. Then compare that forecast range with the ordered product backlog.

For example, suppose six sprints remain and the team’s velocity range is 25 to 35 points per sprint.

The team can forecast:

  • Low end: 6 × 25 = 150 points
  • High end: 6 × 35 = 210 points

The Product Owner and stakeholders can now look at the ordered backlog and discuss what is likely to fit, what is at risk, and what scope decisions may be needed.

Related topic: Fixed-Date Agile Planning

Using a Velocity Range in a Fixed-Scope Plan

A fixed-scope plan starts with a desired set of work.

The planning question is:

When might this set of work be done?

To forecast with a velocity range, divide the total estimated work by the high and low ends of the range. That creates a likely sprint range.

For example, suppose the desired scope is 240 points and the team’s velocity range is 30 to 40 points per sprint.

The team can forecast:

  • Faster case: 240 ÷ 40 = 6 sprints
  • Slower case: 240 ÷ 30 = 8 sprints

The forecast is not “done in exactly seven sprints.” It is more honest to say the work may take roughly six to eight sprints, depending on velocity, scope change, and what the team learns along the way.

Related topic: Fixed-Scope Agile Planning

What to Do with Outliers

Some sprint velocities are unusual.

A team may have one unusually low sprint because several people were on vacation. It may have one unusually high sprint because a lot of nearly finished work finally crossed the finish line.

Those values happened, so they should not be ignored casually. But they may not represent the team’s likely future performance.

That is one reason the trim-highs-and-lows approach can be useful.

It removes unusually high and unusually low values while still using real team data. The team should also use judgment. If an outlier reflects something likely to happen again, such as regular holiday slowdowns or frequent production support, the forecast should account for it.

Do not remove data just because it makes the plan uncomfortable. Remove or adjust for outliers only when there is a clear reason they do not represent future conditions.

Use common sense rather than becoming a slave to the math.

Communicating a Velocity Range to Stakeholders

Stakeholders may prefer a single velocity number.

That is understandable. One number feels simpler. It also feels easier to turn into a date, a commitment, or a budget conversation.

But a single number can hide the uncertainty stakeholders need to understand.

When communicating a velocity range, say something like:

Based on recent history, this team is likely to complete between 25 and 35 points per sprint. With six sprints remaining, that gives us a likely delivery range of 150 to 210 points. The items above 150 are more likely. The items closer to 210 depend on the team performing near the high end of its recent range and scope not growing significantly.

That explanation helps stakeholders see the forecast as a planning tool rather than a promise.

It also creates a better conversation:

  • Which items must be included?
  • Which items are optional?
  • What scope can move if the team tracks near the low end?
  • What assumptions need to remain true?
  • When will we update the forecast?

A good forecast does not eliminate the need for decisions. It improves the decisions people make.

Common Mistakes When Forecasting with Velocity

Using One Average Velocity

Average velocity can be useful, but it should not be the entire forecast. A range usually better reflects reality.

Using Old Velocity Data

Velocity data from years ago may not describe the current team, product, or work. Use recent, relevant data.

Treating the High End as a Commitment

The high end of the range is not a promise. It is one possible outcome.

Ignoring Unknown Work

A velocity range forecasts capacity. It does not automatically account for work that has not yet been discovered. Include an allowance for unknown or emerging work when needed.

Turning Velocity Into a Target

Velocity is a planning input, not a goal. If teams are pressured to increase velocity, they may inflate estimates or change behavior in ways that make forecasts less trustworthy.

Comparing Teams by Velocity

Different teams estimate differently and work in different contexts. Velocity should help a team forecast its own work, not rank teams against one another.

Before You Use a Velocity Range

Before using a velocity range in a milestone forecast, check that:

  • The velocity data comes from the team that will do the work.
  • The data is recent enough to describe the current team and context.
  • The team has completed enough sprints to see a useful pattern.
  • Outliers have been discussed, not ignored automatically.
  • The range is being used as a planning input, not a performance target.
  • Stakeholders understand that the high end is possible, not promised.
  • The forecast also accounts for likely unknown or emerging work.
  • The forecast will be updated as the team learns more.

If several of these are not true, the velocity range may still be useful. But it should be presented as a rough planning aid, not as a reliable milestone forecast.

Common Questions About Velocity Ranges

Why Not Just Use Average Velocity?

Average velocity is precise but often misleading. A range is more likely to reflect what the team will actually experience over future sprints.

How Many Sprints of Data Do We Need?

Use enough recent data to see a pattern. For many teams, three to six months of completed sprints is enough. Avoid relying on old data that no longer reflects the current team.

Should We Use the Median Instead of the Average?

The median can be useful, especially when a few unusual sprints distort the average. But for milestone forecasting, a range is usually more useful than either one number.

What if Stakeholders Push for a Higher Range?

Show the recent data. A range should be grounded in evidence, not wishful thinking. If stakeholders want more work by the date, discuss scope, tradeoffs, or other constraints rather than pretending the team’s velocity will be higher.

What if the Team Has No Velocity Data?

Use a cautious starting range, state the assumptions clearly, and update the forecast as soon as the team completes real work. See the related page on forecasting without velocity data.

Does a Velocity Range Guarantee Delivery?

No. A velocity range supports forecasting. It is not a guarantee. Scope changes, unknown work, team changes, and unexpected risks can all affect the forecast.