Fixed-Scope Agile Planning

Fixed-scope agile planning helps teams answer one common milestone question:

When might this set of work be done?

When the scope is fixed, the forecast should usually be expressed as a time range. The work might be done as early as one date, but could reasonably take until a later date.

Use this page when a set of work matters enough to forecast and stakeholders need to understand when it might realistically be completed.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need to forecast when a desired set of work might be done.

It is especially useful when:

A release, customer commitment, migration, or regulatory need depends on a defined set of work
Stakeholders want one completion date but the evidence supports a range
The team needs to account for unknown or emerging work
The desired scope may need to be split, simplified, or reordered
A fixed scope is being treated as if the date is also guaranteed

What This Page Covers

This page explains how to create a fixed-scope agile forecast by:

Estimating the known scope
Accounting for unknown or emerging work
Using velocity as a range
Calculating a likely sprint range
Converting that sprint range into dates
Communicating timing, assumptions, risks, and tradeoffs clearly

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

What Fixed-Scope Agile Planning Is

A fixed-scope plan starts with a set of work that matters enough to shape the planning conversation.

The scope might be a group of features, a release candidate, a customer commitment, a regulatory need, a migration, or a set of product backlog items needed before a larger launch.

In fixed-scope planning, the scope is the constraint and time becomes the main planning variable.

The team forecasts how many sprints the work may take based on the estimated size of the scope, an allowance for unknown work, and a realistic velocity range.

A good fixed-scope forecast helps the team and stakeholders understand when the work might be completed and how much uncertainty is in that answer.

Fixed-Scope Is Not Fixed-Everything

A fixed-scope plan is not the same as a fixed-everything plan.

In a fixed-scope plan, the desired scope is constrained. Date can still be forecast, discussed, adjusted, or negotiated.

In a fixed-everything plan, someone has already decided both:

Exactly what must be delivered
Exactly when it must be delivered

That is a different conversation.

When both scope and date are fixed, the team is no longer being asked, “When might this set of work be done?” The team is being told, “This much must be done by this date.”

At that point, the useful questions become:

Can we do it?
How risky is it?
What would have to change to make it realistic?

This page focuses on fixed-scope planning, where the scope is fixed enough to forecast but the completion date is still the output of the plan.

The Basic Fixed-Scope Question

Fixed-scope planning answers:

When might this set of work be done?

The answer should usually be a range, not a single date.

A good fixed-scope forecast might say:

Based on the current scope and velocity range, this work may take between eight and ten sprints.

Or:

We might finish as early as late May, but a more cautious forecast would put completion in mid-June.

That is more useful than picking one date and pretending it is certain.

A range helps stakeholders see how scope, velocity, unknown work, and confidence affect the plan.

What You Need Before Creating the Forecast

A fixed-scope forecast needs four inputs:

The estimated size of the known work
An allowance for likely unknown or emerging work
A velocity range for the team
A calendar that maps sprints to dates

The forecast will be weak if any of these inputs are weak.

If the scope is vague, the size estimate will be unreliable. If unknown work is ignored, the forecast will be too optimistic. If the velocity range is unrealistic, the date range will be misleading. If the sprint calendar ignores holidays, vacations, or disrupted sprints, the forecast may look cleaner than reality.

The inputs do not need to be perfect. They need to be good enough to support the decision being made.

Step 1: Estimate the Known Scope

Start by estimating the work the team can see.

This is usually the product backlog items that make up the desired scope. They should be estimated in story points or another consistent unit the team uses for planning.

For fixed-scope planning, the Product Owner and stakeholders should be clear about what is included in the scope.

Ask questions such as:

Which product backlog items are part of this forecast?
Are any items optional?
Are any items still too large or vague to estimate responsibly?
Are defects, technical work, compliance work, or migration work included?
Are there dependencies that may add work later?

The goal is to create a known-scope estimate that is honest enough to forecast against.

Step 2: Account for Unknown Work

A fixed-scope plan should account for work the team has not discovered yet.

The desired scope may look clear at the start, but additional work often appears as the team learns more. Users may identify missing needs. Technical work may emerge. Integration issues may appear. Acceptance criteria may become clearer.

Keep known and unknown work separate when possible. Estimate the known backlog items as honestly as possible, then add an explicit allowance for likely unknown work.

For example, suppose the known scope is estimated at 240 points. If the team believes it currently sees about 80% of the total problem and solution, the adjusted forecast size is:

240 ÷ 0.80 = 300 points

The plan should then be based on 300 points, not 240.

The extra 60 points are not padding. They represent an estimate of work likely to be discovered later.

Step 3: Estimate Velocity as a Range

Next, estimate the team’s velocity as a range.

Do not use a single average velocity if you can avoid it. Teams rarely complete exactly their average velocity every sprint, and a fixed-scope forecast needs to show the likely variation.

For example, instead of saying:

The team completes 30 points per sprint.

Say:

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

That range becomes the basis for the date forecast.

Step 4: Calculate the Sprint Range

Once you know the total forecast size and the velocity range, calculate the sprint range.

Use the high end of the velocity range to calculate the faster case:

Faster case = total size ÷ high velocity

Use the low end of the velocity range to calculate the slower case:

Slower case = total size ÷ low velocity

Fixed-scope forecast formula showing 300 points divided by a velocity range of 30 to 40 points per sprint, resulting in a forecast of about 8 to 10 sprints. — Fixed-scope forecasting turns a total amount of work into a likely sprint range by dividing the forecast size by the team’s velocity range.

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

The calculation is:

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

That gives the team a forecast range of roughly eight to ten sprints.

The answer is not, “This will be done in exactly nine sprints.” The better answer is, “Based on what we know now, this work may take about eight to ten sprints.”

Step 5: Convert Sprints Into Dates

A sprint range becomes more useful when it is converted into dates.

If the team works in two-week sprints, an eight-to-ten-sprint forecast means the work may take about sixteen to twenty weeks.

Then map those sprints to the calendar.

Be careful with the calendar. Holidays, company events, vacations, production freezes, major dependencies, and partial sprints can all affect the forecast.

If the forecast says eight to ten sprints, but one sprint includes a major holiday or a planned company shutdown, the date range should account for that.

A date range should reflect real calendar conditions, not just multiplication.

Example: 300 Points and a Velocity Range

Suppose a team has a desired scope estimated at 300 points.

The team’s velocity range is 30 to 40 points per sprint.

That creates this forecast:

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

Round that to a practical planning range:

This work may take roughly eight to ten sprints.

If the team works in two-week sprints, that is about sixteen to twenty weeks.

The Product Owner and stakeholders can now decide whether that time range is acceptable. If it is not, the conversation should shift to scope, priority, risk, or date expectations.

What to Do When the Date Range Is Too Late

Often, the forecasted date range will be later than stakeholders hoped.

That should not become only the team’s problem.

When stakeholders want the same scope sooner than the forecast supports, planning should become a shared problem. The Product Owner, team, and stakeholders should work together to find the best tradeoff.

Useful options include:

Remove lower-value items from the scope
Split large items so the most valuable part can be delivered earlier
Simplify features while preserving the desired outcome
Move uncertain or risky items earlier to learn sooner
Reduce the unknown-work allowance by learning more
Reconsider the date if the full scope is truly mandatory
Add capacity carefully, understanding that this may not help immediately

The forecast does not make the decision. It makes the decision visible.

Be Careful What You Commit To

A fixed-scope forecast is not automatically a commitment.

The faster end of the range is possible, but less safe. The slower end is more cautious, but may not satisfy stakeholders who hoped for an earlier date.

Use the forecast to decide what the organization is willing to commit to, and be explicit about the risk in that commitment.

Update the Fixed-Scope Forecast as You Learn

A fixed-scope forecast should change as the team learns.

As each sprint finishes, update the likely completion range to reflect completed work, changed velocity, newly discovered scope, risks, dependencies, and changed priorities.

A changing forecast is not a failure. It keeps the forecast useful.

Communicating a Fixed-Scope Forecast

A fixed-scope forecast should be communicated as a time range.

For example:

The current scope is about 300 points. Based on our velocity range of 30 to 40 points per sprint, this work may take roughly eight to ten sprints. That range assumes the scope does not grow significantly and our velocity remains similar to recent history.

That statement is useful because it is specific without pretending to be certain.

It gives stakeholders a basis for deciding:

Is this timing acceptable?
Which items are truly essential?
Which items can be removed, split, or simplified?
Which assumptions need to remain true?
When will we update the forecast?

The forecast should create a conversation about timing, scope, priority, and risk.

Common Mistakes in Fixed-Scope Agile Planning

Treating the Faster Case as a Promise

The faster end of the range is possible, not guaranteed. Do not treat it as a commitment unless everyone understands the risk.

Ignoring Unknown Work

If unknown work is likely, include an allowance for it. Otherwise, the forecast will be too optimistic.

Forecasting from Vague Scope

If the desired scope is vague, the forecast will be vague too. Clarify, split, or refine enough of the work to support the decision being made.

Using One Average Velocity

A single average hides variation. Use a realistic velocity range, especially for milestone forecasts. The Velocity Range Calculator can help derive a range from recent sprint results.

Calling Everything Mandatory

If every item is treated as mandatory, the team has no way to make useful tradeoffs. Push for real prioritization and real conversations about value.

Treating a Forecast as a Commitment

A forecast is a planning tool. A commitment is a promise. Do not silently convert one into the other.

Failing to Update the Forecast

A fixed-scope forecast should change as the team completes work and learns more. Do not defend an old forecast after better information exists.

Before You Use a Fixed-Scope Forecast

Before using a fixed-scope forecast to guide stakeholder decisions, check that:

The desired scope is clear enough to estimate.
The team has separated known work from likely unknown work.
Velocity is represented as a range, not a single optimistic number.
The sprint calendar accounts for holidays, vacations, partial sprints, and known disruptions.
Stakeholders understand that the output is a time range, not a guaranteed date.
The Product Owner knows which items could be removed, split, or simplified if the date range is too late.
The team knows when the forecast will be updated.

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

FAQ

What is fixed-scope agile planning?

Fixed-scope agile planning is milestone planning that starts with a desired set of work and forecasts when that work may be completed.

How is fixed-scope planning different from fixed-date planning?

Fixed-scope planning answers, “When might this set of work be done?” Fixed-date planning answers, “How much can we deliver by this date?”

What should the output of a fixed-scope plan be?

The output should usually be a time range: the work might be completed as early as one date or sprint, but may reasonably take until a later date or sprint.

What if the date and scope are both fixed?

Then the conversation changes. The useful questions become, “Can we do it?” and “How risky is it?” If the forecast shows the work does not fit the date, something needs to change.