Agile Planning and Forecasting

Learn how to create honest milestone forecasts using backlog estimates, unknown work, realistic velocity ranges, and clear constraints—and update those forecasts as new information emerges.

Close

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

Continue with the components of an agile forecast, approaches for fixed-date planning and fixed-scope planning, and ways to create a forecast without velocity data.

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:

  1. Known work: the product backlog items the team has already identified.
  2. Unknown work: work the team has not discovered yet but should expect to emerge.
  3. Velocity as a range: a realistic range of how much work the team may complete per sprint.
  4. 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:

  1. Count how many sprints remain before the date.
  2. Estimate the team's velocity as a range.
  3. Multiply the number of sprints by the low and high values of that velocity range.
  4. 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:

  1. Estimate the total size of the desired work.
  2. Include an allowance for unknown or emerging work.
  3. Estimate the team's velocity as a range.
  4. Divide the total work by the high and low velocity values.
  5. 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.

Using a Single Average Velocity

A single average feels precise, but it hides normal team variability. For more detail, see Velocity Range.

Ignoring Unknown Work

A plan that includes only visible work is usually too optimistic. For more detail, see Estimating Unknown Work.

Updating the Forecast Too Rarely

A forecast should improve as the team learns. For more detail, see Communicating Forecasts.

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.