Components of an Agile Forecast

A useful agile forecast is built from four things: known work, unknown work, a realistic velocity range, and one clear planning constraint.

Those components help teams and stakeholders answer one of two common milestone planning questions:

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

A forecast is not a promise that the future will happen exactly as predicted. It is a way to connect scope, time, team capacity, and uncertainty so people can make better decisions before all the answers are known.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need to create or explain a milestone forecast.

It is especially useful when stakeholders are asking for a plan before the team knows everything, such as when they need to coordinate a launch, fund an initiative, sequence work across teams, or decide what can realistically fit before a target date.

What This Page Covers

This page explains the four inputs every agile forecast needs:

Known work
Unknown work
Velocity as a range
A planning constraint

The same four components apply whether the team is planning toward a fixed date or forecasting when a fixed scope might be done. The calculation changes. The components do not.

Why Forecasts Need More Than a Date

A forecast is not just a date on a calendar.

A useful agile forecast connects the work a team can see, the work it expects to discover, the rate at which the team tends to finish work, and the constraint that matters most.

That matters because many planning conversations start with incomplete information. Stakeholders may need a forecast before every product backlog item is fully refined, before every dependency is known, or before the team has learned everything it will learn during development.

A good forecast does not pretend the future is certain. It makes the assumptions and uncertainty visible enough that people can discuss tradeoffs earlier.

The Four Components of an Agile Forecast

A milestone forecast needs four 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.

Forecast update format showing six parts: current forecast, change since last update, assumptions, risks, decision needed, and next update. — A useful forecast update separates the current forecast, what changed, the assumptions and risks, the decision needed, and when the forecast will be updated again.

These components work together. Known work gives the team something to forecast against. Unknown work keeps the forecast from being artificially optimistic. Velocity as a range reflects the variation real teams experience. The planning constraint determines which question the forecast is answering.

Component 1: Known Work

Known work is the work the team can already see.

In most agile planning conversations, this is the product backlog: the product backlog items the team and Product Owner have identified, discussed, and estimated.

Known work might include:

User stories
Product backlog items
Technical work that is already visible
Defects the team has decided to include in the plan
Compliance, migration, infrastructure, or integration work that is already understood

This is usually the part of the forecast teams are most comfortable with. They can point to the items, discuss them, estimate them, and order them.

The forecast is only as good as this input. If the known work is vague, oversized, unestimated, or poorly ordered, the forecast will be weak.

That does not mean every product backlog item must be perfectly refined before forecasting. It means the team needs enough understanding to support the decision being made. For more detail, see Story Points.

Component 2: Unknown Work

Unknown work is the work the team has not discovered yet.

That may sound impossible to estimate. And, of course, the team cannot precisely estimate work it does not yet know.

But pretending unknown work does not exist makes the forecast look more certain than it is.

Unknown work may include:

Product backlog items discovered during development
Technical work that becomes visible only after implementation begins
Integration work that turns out to be harder than expected
Edge cases or user needs discovered through feedback
Rework caused by new information
Compliance, data, deployment, or operational work that was not obvious at first

A forecast that includes only known work may be useful for a very short horizon. But for a milestone several sprints away, unknown work almost always matters.

A good starting point is to keep known and unknown work separate in the forecast. Estimate the known product backlog items as well as the team reasonably can. Then add an explicit allowance for likely unknown work rather than hiding that uncertainty inside individual estimates.

The farther away the milestone is, the larger that allowance may need to be.

The goal is not to know the unknowable. The goal is to leave room in the plan for the work experience tells us is likely to emerge. For more detail, see Estimating Unknown Work in Agile Plans.

Component 3: Velocity as a Range

Velocity is how much work a team completes in a sprint, usually measured in story points.

Many teams forecast with an average velocity. If the team’s recent velocities average 35 points per sprint, they plan as if the team will complete 35 points in each future sprint.

That is simple, but it can be misleading.

A team that averages 35 points may complete 28 points one sprint, 37 the next, 31 the next, and 40 after that. The average may be useful, but it does not show the variation the team actually experiences.

That is why milestone forecasts should usually use velocity as a range.

Instead of saying:

The team will complete 35 points per sprint.

Say:

Based on recent history, the team is likely to complete between 28 and 40 points per sprint.

A velocity range makes uncertainty visible. It helps stakeholders see what is likely, what is optimistic, and what may be at risk. For more detail, see Forecasting with a Velocity Range.

Tool: Velocity Range Calculator

Component 4: a Planning Constraint

The final component is the planning constraint.

Most milestone planning starts with one of two constraints:

A fixed date
A fixed scope

A fixed-date plan starts with a date that cannot easily move. A conference, regulatory deadline, customer launch, or contract commitment may create that date. The question becomes:

How much can we deliver by that date?

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

When might this set of work be done?

Trying to fix both date and scope while ignoring uncertainty usually leads to a bad plan. Agile planning works best when people are honest about the constraint and clear about what can change.

If the date is fixed, scope becomes the primary planning variable.

If the scope is fixed, date becomes the primary planning variable.

How the Components Work in a Fixed-Date Plan

A fixed-date plan answers:

How much can we deliver by this date?

The basic process is:

Count how many sprints remain before the fixed date.
Estimate the team’s velocity as a range.
Multiply the number of sprints by the low and high velocity values.
Compare that forecast range with the ordered product backlog.
Use the result to discuss likely scope, risky scope, and tradeoffs.

Suppose eight sprints remain and the team’s velocity range is 25 to 35 points per sprint.

That gives a forecast range of:

Low end: 8 × 25 = 200 points
High end: 8 × 35 = 280 points

If the Product Owner has 240 points of known work, that work is within the feasible range. But if the team expects additional work to emerge during those eight sprints, completing all 240 known points may still be risky.

That is the value of the forecast. It helps the team and stakeholders see the tradeoff early. For more detail, see Fixed-Date Agile Planning.

How the Components Work in a Fixed-Scope Plan

A fixed-scope plan answers:

When might this set of work be done?

The basic process is:

Estimate the size of the known work.
Add 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 result into a likely sprint range or date range.

Suppose the desired scope is 300 points and the team’s velocity range is 30 to 40 points per sprint.

The forecast would be:

Faster case: 300 ÷ 40 = 7.5 sprints
Slower case: 300 ÷ 30 = 10 sprints

That does not mean the work will definitely take exactly 8 to 10 sprints. It means the team has a reasonable forecast range to use in planning conversations.

Stakeholders can then decide whether to keep the scope, adjust the date, split the work, change priorities, or accept the uncertainty. For more detail, see Fixed-Scope Agile Planning.

Why the Same Components Work for Both Plans

Fixed-date and fixed-scope planning look different, but they rely on the same ingredients.

In both cases, the team needs to know:

What work is already known
What unknown work should be expected
How much work the team is likely to complete per sprint
Whether the plan is constrained by date or scope

The difference is the question being answered.

In a fixed-date plan, the number of sprints is known, so the team forecasts how much scope may fit.

In a fixed-scope plan, the scope is known, so the team forecasts how many sprints may be needed.

That distinction keeps planning conversations clearer. It also prevents teams and stakeholders from pretending date, scope, and uncertainty can all be fixed at the same time.

A Forecast Should Start a Conversation

The output of an agile forecast is not just a number or date.

It should start a conversation about decisions:

Which items are essential?
Which items are optional?
What scope can move if velocity is near the low end?
What new work might emerge?
What assumptions need to remain true?
How often will we update the forecast?
What will we do if the forecast changes?

The forecast is useful because it helps people see the consequences of their choices.

A forecast that says “everything will be done by June 30” is easy to understand but often misleading. A forecast that says “we are likely to deliver between these two points in the ordered backlog by June 30” is more useful because it shows the tradeoff.

Common Mistakes When Building an Agile Forecast

Ignoring Unknown Work

A plan based only on known work may look good but fail when new work appears. Leave room for the work that is likely to emerge.

Using a Single Velocity Number

A single average velocity can hide variation. Use a realistic range, especially for milestone forecasts. For more detail, see Velocity Range Calculator.

Treating the Forecast as a Commitment

A forecast is a planning tool. A commitment is a promise. Confusing the two encourages teams to hide uncertainty or inflate estimates.

Fixing Both Date and Scope Without Tradeoffs

If both date and scope are fixed, something else must give. Usually quality, trust, or sustainability suffers.

Forgetting to Update the Forecast

A forecast should change as the team learns. A plan that never changes despite new information is usually less trustworthy, not more.

Before You Build an Agile Forecast

Before using a forecast to support a milestone decision, check that these things are true:

The team has identified the known work well enough to discuss and estimate it.
The Product Owner has ordered the work according to current priorities.
The team has made an explicit allowance for unknown or emerging work.
Velocity is represented as a realistic range, not a single optimistic number.
Everyone knows whether the plan is constrained by date or by scope.
Stakeholders understand what may need to change if the forecast changes.
The team knows when the forecast will be updated.

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

FAQ

What is the most important input to an agile forecast?

There is no single most important input. A forecast needs known work, an allowance for unknown work, a velocity range, and a planning constraint. Weakness in any one of those can distort the plan.

Do we need every backlog item estimated before forecasting?

No. You need enough estimates to support the decision being made. Near-term or high-priority work should usually be better understood than work farther out.

How do we estimate work we do not know yet?

You cannot estimate unknown work precisely. But you can account for likely unknown work based on experience, product uncertainty, similar past efforts, and the length of the forecast horizon.

Why use velocity as a range?

Teams rarely complete exactly the same amount of work every sprint. A range reflects actual variation and makes the forecast more honest.

What if both date and scope are fixed?

Then the plan should make the risk explicit. If the forecast shows the desired scope does not fit the date, stakeholders need to decide whether to reduce scope, move the date, add capacity carefully, or accept the risk.