Forecasting Without Velocity Data

Forecasting without velocity data is risky, but sometimes a team has to do it.

When that happens, create a cautious first forecast, make the assumptions clear, and replace it with real data as soon as possible.

Use this page when a team needs to forecast a milestone but does not yet have reliable velocity data from completed sprints.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need an early milestone forecast before the team has enough completed-sprint data.

It is especially useful when:

A team is new and has not established a velocity pattern
A team has not yet completed enough product backlog items to forecast from history
Stakeholders need an initial forecast before the first sprint finishes
A funding, launch, or coordination decision cannot wait
Leaders need to understand why an early forecast should be treated cautiously

What This Page Covers

This page explains how to create a cautious first forecast when velocity data is not yet available.

You will learn why no-data forecasts are risky, why one sprint of real data is better than none, how to use capacity-driven sprint planning as a fallback, how to turn the result into a conservative range, and when to replace the forecast with real data.

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

Start with a Warning

The best way to forecast velocity is to use actual velocity data from the team that will do the work.

When you do not have that data, be careful.

You are trying to estimate the speed of a team that may not have worked together before, may not have worked this way before, or may not have delivered enough completed product backlog items to establish a pattern.

That is risky.

So the first question should be:

Can we avoid giving a forecast until we have at least one sprint of real data?

Sometimes the answer is no. A stakeholder needs a date. A funding decision is due. A larger plan depends on a first forecast.

But the warning still matters: a forecast without velocity data should sound less confident than a forecast based on several completed sprints.

Best Option: Get One Sprint of Real Data

If possible, get the team started and run one sprint before giving the forecast.

One sprint of data is not enough to make a highly reliable forecast. But one sprint of real data is much better than no data.

This can sometimes be easier than it sounds.

Stakeholders may be used to teams taking a couple of weeks to create a detailed traditional plan. Instead of spending that time building a Gantt chart, an agile team can often start work, complete a sprint, and use the result as the first velocity data point.

The team can then say:

We have completed one sprint. This is still early, but we now have at least one real data point to use in the forecast.

That first data point should still be turned into a range. But it gives the team a more grounded starting point than pure speculation.

When You Cannot Wait for One Sprint

Sometimes teams do not have time to run a sprint and get data.

Stakeholders may need an initial forecast before the first sprint finishes. In that case, use a cautious substitute: have the team plan a sprint and use the amount of work it believes can fit as an initial velocity estimate.

This is not as good as actual velocity.

It is a simulation, not evidence from completed work.

But it can be useful when everyone understands what it is: an early estimate that should be replaced as soon as real data exists.

Use Capacity-Driven Sprint Planning

A practical way to estimate velocity without data is to run a capacity-driven sprint planning exercise.

This assumes the product backlog items have already been estimated in story points. The team will not use those points to decide what fits. Instead, it will plan based on capacity and task work.

A simple process looks like this:

Start with the highest-priority product backlog item.
Discuss what tasks would be needed to complete it.
Roughly estimate the task work in hours.
Compare the task work with the team’s available capacity.
If the item fits, add it to the simulated sprint.
Move to the next product backlog item and repeat.
Stop when the team believes the sprint is full.
Add up the story points on the selected product backlog items.

That sum becomes the team’s first estimated velocity.

During the planning exercise, the team should not be asking, “How many story points should fit?” It should be asking, “Given our available time and the work we think is involved, can we responsibly take this item?”

Only after the simulated sprint feels full should the team add up the points.

A Simple Example

Suppose a team has estimated its product backlog in story points.

The team has no velocity history, so it plans a simulated first sprint using capacity-driven planning.

After discussing tasks, capacity, and availability, the team decides it can take three product backlog items into the sprint. Those items are estimated at 5, 5, and 3 points.

Add those together:

5 + 5 + 3 = 13

The team’s first estimated velocity is 13 points.

But do not use 13 as a single-number forecast.

Turn it into a range.

Turn the Estimate Into a Range

A single estimated velocity is too precise, especially when it is not based on completed work.

Teams often overestimate what they can do, especially in their first sprint or first few sprints. They may underestimate interruptions, collaboration time, testing, review, integration, or the learning needed to finish work.

So after the team estimates a starting velocity, convert it into a cautious range.

For example, suppose the team plans 40 points into the simulated sprint.

If the team took the planning seriously and talked through the items carefully, a possible starting range might be:

30 to 40 points

If the team rushed the planning, a more cautious range might be:

25 to 35 points

If the team really rushed the planning, the better answer may be to ask the team to plan another sprint more carefully. If that is not possible, use an even more cautious range, such as:

20 to 30 points

The exact range is a judgment call. The important point is that the forecast should reflect the uncertainty of having no actual velocity data.

Why the Range Should Be Conservative

Teams are often optimistic when planning their first sprint.

That does not mean they are careless or dishonest. It means they may be new to the work, new as a team, new to agile, or new to the product. They may not yet know what will slow them down.

So if a team plans 40 points into a simulated sprint, the high end of the range does not have to be 40.

If the team rushed the exercise, a 25 to 35 point range may be more realistic than 30 to 40.

That can feel conservative. But the purpose of the forecast is not to reward optimism. It is to help people make better decisions.

Use the Starting Range in a Forecast

Once you have a starting velocity range, use it the same way you would use any velocity range.

For a fixed-date plan, multiply the number of remaining sprints by the low and high ends of the range.

For example, if six sprints remain and the starting range is 25 to 35 points:

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

For a fixed-scope plan, divide the total estimated work by the high and low ends of the range.

For example, if the desired scope is 180 points and the starting range is 25 to 35 points:

Faster case: 180 ÷ 35 = about 6 sprints
Slower case: 180 ÷ 25 = about 8 sprints

Because this range is not based on completed work, communicate it cautiously. It is a starting forecast, not a reliable pattern. For more detail, see Forecasting with a Velocity Range.

Replace the Forecast as Soon as Real Data Exists

A forecast made without velocity data should have a short shelf life.

As soon as the team completes a sprint, update the forecast. The first sprint gives the team one real data point. A few more sprints will give the team a better pattern.

Do not defend the original forecast just because it was the first one communicated.

The purpose of the early forecast is to help with early decisions. As better information becomes available, use it.

Update the forecast when:

The team completes its first sprint.
The team completes several sprints and a pattern begins to emerge.
Scope changes.
Team membership changes.
The team discovers unexpected work.
The team learns that its initial capacity assumptions were wrong.

A forecast without data should become a forecast with data as quickly as possible. For more detail, see Updating and Communicating Agile Forecasts.

Communicating the Forecast to Stakeholders

Do not present a no-data forecast as if it were based on history.

Say something like:

We do not yet have completed-sprint velocity data for this team. We created this forecast by having the team plan a sprint using capacity and task estimates, then converting that result into a cautious velocity range. We will update the forecast after the first sprint and again as more data becomes available.

That framing matters.

It tells stakeholders the forecast is useful, but early. It also prepares them for change. A no-data forecast should be expected to change as soon as real evidence appears.

Common Mistakes When Forecasting Without Velocity Data

Pretending the Forecast Is Reliable

A forecast without velocity data is an early estimate. Treat it that way.

Using a Single Velocity Number

Do not plan from one value. Turn the estimated velocity into a range. For more detail, see Velocity Range Calculator.

Letting the Team Pull in Too Much Work

Teams often overestimate what they can do at first. Be cautious, especially if the team rushed the planning exercise.

Using Another Team’s Velocity

Another team’s velocity is rarely a good substitute. Different teams estimate differently, have different skills, face different constraints, and work in different contexts. For more detail, see Know Exactly What Velocity Means to Your Scrum Team.

Waiting Too Long to Replace the Forecast

Once real sprint data exists, update the forecast. The no-data forecast should not linger longer than necessary.

Forgetting Unknown Work

Even a cautious velocity range only forecasts team capacity. The plan still needs to account for work that has not yet been discovered. For more detail, see Know Exactly What Velocity Means to Your Scrum Team.

Before You Forecast Without Velocity Data

Before creating a no-data forecast, ask:

Can the team complete one sprint before the forecast is needed?
Are the product backlog items estimated well enough to support a simulated sprint?
Has the team planned from real capacity rather than a desired point total?
Did the team discuss the task work needed to complete the selected items?
Is the starting velocity expressed as a cautious range?
Have you made clear that the forecast is not based on completed-sprint history?
Do stakeholders know when the forecast will be replaced with real data?
Does the plan still account for likely unknown work?

If several of these are not true, the forecast may still be necessary. But it should be communicated as a rough early estimate, not as a reliable delivery forecast.

FAQ

Should we forecast if we have no velocity data?

Avoid it if possible. It is better to complete at least one sprint and use that as a starting point. If stakeholders need an answer before then, create a cautious forecast and make the uncertainty clear.

Is one sprint of velocity data enough?

One sprint is not enough for a highly reliable forecast, but it is better than no data. Use it cautiously and update the forecast as more sprints are completed.

Can we use another team’s velocity?

Avoid that if possible. Another team’s velocity may be based on a different estimating scale, different skills, different work, and different constraints. Use the actual team’s data as soon as it exists.

What is capacity-driven sprint planning?

Capacity-driven sprint planning means the team decides what fits in a sprint by looking at available capacity and the task work needed to complete product backlog items. The story points on the selected items are added only after the sprint feels full.

Why turn the estimate into a range?

Because the estimate is uncertain. A range communicates that uncertainty better than one number.

What if the team plans 40 points into the sprint?

Do not automatically use 40 as the forecast. If the team planned carefully, a range such as 30 to 40 may be reasonable. If the team rushed, 25 to 35 or even 20 to 30 may be more appropriate.