Agile Planning and Forecasting: How to Forecast Milestones

Agile teams plan at many levels. This guide focuses on one of the hardest: milestone planning and forecasting across multiple sprints.

Milestone forecasts help teams and stakeholders answer two questions they often care about:

How much can we deliver by this date?
When might this set of work be done?

Use this guide to forecast milestones using a product backlog, story point estimates, a realistic velocity range, and an honest view of uncertainty.

Who This Guide Is For

This guide is for Product Owners, Scrum Masters, agile coaches, leaders, and stakeholders who need useful milestone forecasts without pretending the future is certain.

It is especially useful for:

Product Owners who need to forecast dates, scope, milestones, or release options
Scrum Masters and agile coaches helping teams improve planning conversations
Leaders and stakeholders who need transparency without pressuring teams into false certainty
Teams using story points and velocity to plan beyond a single sprint
Organizations whose current plans are too precise too early or do not show changing scope clearly
New or changing teams that need to forecast before they have much velocity data

Milestone planning is not about locking a team into a perfect prediction. It is about creating a useful forecast, making assumptions visible, and updating the forecast as the team learns.

In This Guide

This guide explains what milestone planning and forecasting means in agile, how it differs from story point estimating, and what goes into a useful multi-sprint forecast.

It does not try to cover every kind of agile planning. Sprint Planning, daily planning, roadmap planning, and portfolio planning are related topics, but this guide concentrates on the forecasts teams use to reason about scope, dates, milestones, and release options.

You will learn how to forecast with known work, unknown work, velocity ranges, and fixed-date or fixed-scope constraints. You will also find common forecasting mistakes, a practical pre-forecast check, curated next steps, and a related live course for teams that want to improve milestone planning conversations.

What This Guide Means by Agile Planning and Forecasting

Agile teams plan at many levels.

They plan each sprint. They plan each day. They plan milestones, products, portfolios, and strategic initiatives. This guide focuses on the planning level that sits above individual sprints: milestone planning and forecasting.

Milestone planning, historically called release planning, looks ahead several sprints and forecasts what may be delivered by a future date or when a desired set of work may be completed.

That type of planning matters because stakeholders often need to make decisions before every detail is known. They may need to decide whether to fund an initiative, announce a date, sequence work across teams, coordinate with marketing or sales, or choose between competing product options.

A useful agile forecast does not pretend to remove uncertainty. It makes uncertainty visible enough that people can make better decisions.

How This Guide Is Different from Story Point Estimating

Estimating and forecasting are related, but they are not the same topic.

For guidance on estimating product backlog items, see Story Points.

This guide focuses on what happens after estimates exist: using those estimates, velocity, and uncertainty to forecast milestones.

Story point estimates are one input into a plan. They are not the plan itself.

A milestone forecast also needs a product backlog, a sense of known and unknown work, a velocity range, a target date or target scope, and a way to update the plan as the team learns.

What Goes Into an Agile Forecast?

A useful agile forecast has four main components:

Known work: the product backlog items the team has already identified.
Unknown work: work the team has not discovered yet but should expect to emerge.
Velocity as a range: a realistic range of how much work the team may complete per sprint.
A planning constraint: either a fixed date or a fixed scope.

These components help a team answer one of two common planning questions:

Fixed-date question: How much can we deliver by this date?
Fixed-scope question: When might this set of work be done?

Both questions are reasonable. They just require different planning calculations and different stakeholder conversations.

Putting the Forecast Together

Suppose a team has eight sprints before an important milestone. Its recent velocity suggests it will likely complete between 25 and 35 points per sprint.

That gives the team a forecast range of 200 to 280 points by the milestone.

Now suppose the Product Owner has identified 240 points of known work. That is within the feasible range given the team's velocity and the number of sprints remaining.

However, over eight sprints, it is very likely that new needs will be discovered. That makes completing all 240 points of already-known work riskier than the range alone suggests. The team might still hit the date, but only if scope is managed carefully or the team performs near the high end of its velocity range.

That is the value of an agile forecast. It does not say, "Everything will be fine." It helps the team and stakeholders see the tradeoffs early enough to do something about them.

Estimating What You Know and What You Do Not Know

Most teams can estimate the work they can see.

That known work is represented by the product backlog: the product backlog items the team and Product Owner have identified, discussed, and estimated.

But a product backlog rarely contains everything that will be needed. Some work is discovered only after development begins. Some requirements emerge when users see early increments. Some technical work becomes visible only after the team starts building.

A useful agile forecast accounts for both:

The product backlog items already known
The likely work that has not been discovered yet

That second category will never be perfectly estimated. But ignoring it makes the plan look more certain than it is.

Good milestone planning does not require pretending unknown work is knowable. It requires acknowledging that unknown work exists and representing it in the forecast.

Why Velocity Should Be a Range

Many teams forecast using average velocity.

That is understandable, but it can be misleading. If a team's past sprint velocities were 27, 34, 36, 31, 29, and 35, the average may be useful, but it is not the whole story.

The team probably will not complete exactly its average velocity in the next sprint. And it is even less likely to complete exactly its average velocity every sprint for the next several sprints.

A velocity range is more honest.

Instead of saying, "This team will complete 33 points per sprint," say something like:

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 milestone outcomes.

If there are five sprints before a target date, the team might forecast 135 to 180 points of completed work. That is more useful than a single number because it shows uncertainty and supports better tradeoff decisions.

Related tool: Velocity Range Calculator

Fixed-Date Planning: How Much Can We Deliver by This Date?

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

A conference, regulatory deadline, contract commitment, marketing event, or customer rollout may create a fixed date. The planning question becomes:

How much can we deliver by that date?

A simple fixed-date forecast works like this:

Count how many sprints remain before the date.
Estimate the team's velocity as a range.
Multiply the number of sprints by the low and high values of that velocity range.
Compare that range with the ordered product backlog.

For example, if five sprints remain and the team's velocity range is 27 to 36 points, the team can forecast roughly 135 to 180 points by the date.

That does not mean every item below 180 points will definitely be delivered. It means the team can now have a better conversation about what is likely, what is risky, and what tradeoffs are available.

Fixed-Scope Planning: When Might This Be Done?

A fixed-scope plan starts with a desired set of features or product backlog items.

The planning question becomes:

When might this set of work be done?

A simple fixed-scope forecast works like this:

Estimate the total size of the desired work.
Include an allowance for unknown or emerging work.
Estimate the team's velocity as a range.
Divide the total work by the high and low velocity values.
Convert the resulting sprint range into a date range.

For example, if the desired scope is 300 points and the team's velocity range is 30 to 40 points per sprint, the forecast might be 8 to 10 sprints.

That range helps stakeholders understand the likely timing and make tradeoff decisions. They might reduce scope, add time, change priority, or accept the uncertainty.

Forecasting Without Velocity Data

Sometimes a team needs to forecast before it has reliable velocity data.

That happens with new teams, teams new to agile, teams that have not tracked velocity, or teams that have changed significantly.

The best answer is to get data as quickly as possible. Run a sprint. Finish real product backlog items. Use that result as a starting point. Even one sprint of actual data is better than no data.

But sometimes stakeholders need a forecast before the team has that first data point.

In that case, create a forecast cautiously. Use a range. State the assumptions. Make the uncertainty obvious. Update the forecast as soon as real data appears.

A forecast without velocity data should never sound as confident as a forecast based on several completed sprints.

Updating the Forecast as You Learn

An agile forecast should change as the team learns.

At the end of each sprint, the team knows more than it knew before. It has completed some work, discovered new work, learned more about the product, and gathered better information about velocity.

Update the forecast when:

The team completes work
Scope changes
New work emerges
Velocity changes
Risks become clearer
Stakeholders change priorities
Product backlog items are split, removed, or added

A changing forecast is not a failure. A forecast that never changes despite new information is usually less trustworthy.

Communicating Forecasts to Stakeholders

A forecast is not a commitment.

That does not mean forecasts are useless. It means they should be communicated honestly.

Good forecast communication includes:

A range rather than a single overly precise date or scope number
The assumptions behind the forecast
What is included and what is not included
What changed since the last forecast
The tradeoffs available if the forecast is not acceptable
The team's confidence level

Stakeholders do not need false certainty. They need enough visibility to make responsible decisions.

A good agile forecast helps them see the consequences of scope, date, and confidence tradeoffs.

Common Agile Forecasting Mistakes

Most agile forecasting problems are not caused by planning. They are caused by planning as if uncertainty does not exist.

Treating a Forecast as a Commitment

A forecast is a planning tool. A commitment is a promise.

When leaders or stakeholders treat every forecast as a commitment, teams learn to hide uncertainty, inflate estimates, or avoid giving honest updates. That makes planning less useful, not more reliable.

Using a Single Average Velocity

A single average may feel precise, but it often hides the variability every team experiences.

A velocity range gives stakeholders a more honest picture of what is likely, what is possible, and where the risk sits.

Ignoring Unknown Work

If the plan includes only the work the team can already see, the forecast will usually be too optimistic.

Unknown work is not a sign the team planned poorly. It is a normal part of product development. The forecast should make room for it.

Updating the Forecast Too Rarely

An agile forecast should improve as the team learns.

If the forecast is not updated when scope changes, velocity changes, risks appear, or priorities shift, it becomes a historical artifact rather than a useful planning tool.

Hiding Tradeoffs

A forecast should help stakeholders make decisions.

If the plan does not show the tradeoffs among scope, date, team capacity, and confidence, stakeholders may think they have more certainty than they actually do.

Before You Share a Milestone Forecast

Use these questions to check whether the forecast is ready for a useful stakeholder conversation.

Is the planning question clear: fixed date or fixed scope?
Is the known work represented by an ordered product backlog?
Has the team allowed for unknown or emerging work?
Is velocity shown as a realistic range rather than a single average?
Are the assumptions behind the forecast visible?
Is the forecast clear about what is included and what is not included?
Are the main risks and tradeoffs visible?
Does the forecast make it clear what decisions stakeholders need to make?
Is there a plan for updating the forecast as the team learns?

This is not a gatekeeping checklist. Use it to make sure the forecast supports a better conversation instead of creating false certainty.

FAQ

Is Milestone Planning the Same as Sprint Planning?

No. Sprint planning is a Scrum event focused on what the team will do in the next sprint. This guide focuses on milestone planning and forecasting across multiple sprints.

What Is a Milestone Plan?

A milestone plan is a forecast of what may be delivered by a future date or when a larger set of work may be completed. It often spans several sprints.

Why Use a Velocity Range Instead of Average Velocity?

A range better reflects reality. Teams rarely complete exactly their average velocity every sprint. A range makes uncertainty visible and helps stakeholders make better decisions.

What If We Do Not Have Velocity Data?

Get real data as quickly as possible. If a forecast is needed before that, use a cautious range, state the assumptions, and update the forecast as soon as real data exists.

What Is a Fixed-Date Plan?

A fixed-date plan answers, "How much can we deliver by this date?" The date is constrained, so scope becomes the variable.

What Is a Fixed-Scope Plan?

A fixed-scope plan answers, "When might this set of work be done?" The scope is constrained, so date becomes the variable.

How Often Should We Update a Forecast?

Update the forecast whenever the team has meaningful new information. For many Scrum teams, that means at least at the end of each sprint.

Is a Forecast a Commitment?

No. A forecast is a planning tool. A commitment is a promise. Treating every forecast as a commitment encourages teams to hide uncertainty or inflate estimates.