Fixed-Date Agile Planning
Fixed-date agile planning helps teams answer one common milestone question:
How much can we deliver by this date?
When the date is fixed, the forecast should usually be expressed as a scope range: what the team will likely have, might have, and probably will not have by that date.
Use this page when a date cannot easily move and stakeholders need to understand what scope may be realistic by that date.
Who This Page Is For
This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need to plan toward a date that matters.
It is especially useful when:
- A launch, event, customer commitment, contract, or regulatory date cannot easily move
- Stakeholders want to know what can realistically fit before a deadline
- A team needs to separate likely scope from risky scope
- The Product Owner needs help making priority tradeoffs
- A fixed date is being treated as if fixed scope is also guaranteed
What This Page Covers
This page explains how to create a fixed-date agile forecast by:
- Counting the sprints available before the date
- Using velocity as a range
- Applying that range to an ordered product backlog
- Separating scope into will-have, might-have, and will-not-have areas
- Accounting for unknown work
- Communicating scope, risk, and tradeoffs clearly
If you need the forecasting inputs first, start with The Components of an Agile Forecast.
What Fixed-Date Agile Planning Is
A fixed-date plan starts with a deadline that matters enough to shape the planning conversation.
The date might come from a conference, a regulatory deadline, a contract, a marketing launch, a seasonal business window, or a customer commitment.
In fixed-date planning, the date is the constraint and scope becomes the main planning variable.
The team forecasts which product backlog items are likely to fit by the deadline, which items are uncertain, and which items are unlikely to fit unless something changes.
A good fixed-date forecast helps the team and stakeholders make scope and priority decisions early, while there is still time to adjust the plan.
Fixed-Date Is Not Fixed-Everything
A fixed-date plan is not the same as a fixed-everything plan.
In a fixed-date plan, the date is constrained. Scope can still be discussed, ordered, split, reduced, deferred, or changed.
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, “How much can we deliver by this date?” 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-date planning, where the date is fixed but scope can still be forecast and managed.
The Basic Fixed-Date Question
Fixed-date planning answers:
How much can we deliver by this date?
The answer should usually be a range, not a single list of guaranteed features.
A good fixed-date forecast separates the backlog into three areas:
- Will have: work that is likely to be completed by the date
- Might have: work that could be completed if things go well
- Will not have: work that is unlikely to be completed by the date
This gives stakeholders a more useful answer than, “We’ll try to get as much done as we can.”
It also avoids the false certainty of saying, “All of this will be done,” when the forecast does not support that.
What You Need Before Creating the Forecast
A fixed-date forecast needs four inputs:
- The number of sprints remaining before the date
- A velocity range for the team
- An ordered product backlog
- An allowance for likely unknown or emerging work
The forecast will be weak if any of these inputs are weak.
If the team does not know how many sprints remain, the timebox is unclear. If the velocity range is unrealistic, the forecast will be misleading. If the product backlog is poorly ordered, the scope forecast will not reflect real priorities. If unknown work is ignored, the forecast will look better than it should.
The inputs do not need to be perfect. They need to be good enough to support the decision being made.
Related topic: The Components of an Agile Forecast
Step 1: Determine How Many Sprints Remain
Start by counting how many sprints remain before the fixed date.
If the team works in two-week sprints and there are twelve weeks before the target date, the team has six sprints available.
Be careful not to count partial or disrupted sprints as if they were full-strength sprints. Holidays, company events, vacations, team changes, and major dependencies can all affect how much work is realistic.
If the team has six calendar sprints before the date but one of them includes a major holiday, the forecast may need to account for that.
Step 2: 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 milestone forecast needs to show that 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 30 points per sprint.
That range becomes the basis of the fixed-date forecast.
Related topic: Forecasting with a Velocity Range
Step 3: Calculate Will Have and Might Have
Once you know the number of sprints and the velocity range, calculate two numbers.
The lower number marks the will-have line:
Will have = low velocity × number of sprints
The higher number marks the might-have line:
Might have = high velocity × number of sprints
For example, suppose the team has six sprints before the fixed date and a velocity range of 25 to 30 points.
The calculation is:
- Will have: 6 × 25 = 150 points
- Might have: 6 × 30 = 180 points
That gives the team a scope range. The team is likely to complete about 150 points and may complete as many as 180 if things go well.
Step 4: Count Down the Ordered Product Backlog
Now apply the forecast to the ordered product backlog.
Start at the top of the backlog and count down by story points.
Items above the low-velocity line are in the will-have area. These are the items the team is most likely to complete by the date.
Items between the low-velocity line and the high-velocity line are in the might-have area. These are possible, but less certain.
Items below the high-velocity line are in the will-not-have area. These are unlikely to be completed by the date unless something changes.
This is where fixed-date planning becomes useful. The forecast turns a date into a visible scope conversation.
Stakeholders can see which items are likely, which are at risk, and which are outside the likely range.
Example: Six Sprints and a Velocity Range
Suppose a team has six sprints before a target date.
Its velocity range is 25 to 30 points per sprint.
That creates this forecast:
- Will have: 150 points
- Might have: 180 points
Now suppose the ordered product backlog contains 220 points of work.
The Product Owner can count down the backlog and identify:
- The items in the first 150 points: likely to be delivered
- The items from 151 to 180 points: possible, but at risk
- The items after 180 points: unlikely by the date
The answer is not, “We will deliver 180 points.”
The better answer is:
By the target date, we are likely to have the highest-priority 150 points. We might have up to 180 points if things go well. Items beyond that should not be planned as part of the milestone unless scope, date, or assumptions change.
Account for Unknown Work
A fixed-date plan should account for work the team has not discovered yet.
If the ordered backlog contains 150 points and the team’s will-have line is also 150 points, the plan may look safe. But if the team expects new work to appear during the milestone, the plan is riskier than it looks.
Unknown work can include:
- Product backlog items discovered during development
- Technical work that becomes visible later
- Integration or deployment work that was missed
- Feedback-driven changes
- Rework from new information
Keep known and unknown work separate when possible. Estimate known backlog items as honestly as possible, then add an explicit allowance for likely unknown work.
Related topic: Estimating Unknown Work in Agile Plans
What to Do When the Desired Scope Does Not Fit
Often, the desired scope will not fit the fixed date.
That should not become only the team’s problem.
When stakeholders want more than the team is likely to deliver by the date, 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-priority items from the milestone
- Split large items so the most valuable part can be delivered first
- Simplify features while preserving the desired outcome
- Move uncertain items earlier to learn sooner
- Reduce or defer optional scope
- Reconsider the date if the truly mandatory scope does not fit
- Add capacity carefully, understanding that this may not help immediately
The forecast does not make the decision. It makes the decision visible.
Recommended article: When Planning Should Become a Shared Problem
Be Careful What You Commit To
A fixed-date forecast is not automatically a commitment.
The will-have area is safer than the might-have area, but it is still a forecast. Teams can be interrupted. Scope can change. Hidden work can appear. Dependencies can slip.
Use the forecast to decide what the organization is willing to commit to, and be explicit about the risk in that commitment.
Related topic: Updating and Communicating Agile Forecasts
Update the Fixed-Date Forecast as You Learn
A fixed-date forecast should change as the team learns.
As each sprint finishes, update the will-have, might-have, and will-not-have ranges 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-Date Forecast
A fixed-date forecast should be communicated as a scope range.
For example:
We have six sprints before the target date. Based on our current velocity range, we are likely to complete the first 150 points in the backlog and might complete up to 180 points if things go well. Items beyond 180 should not be assumed for the milestone.
That statement is useful because it is specific without pretending to be certain.
It gives stakeholders a basis for deciding:
- Which items are truly essential?
- Which items can move out of the milestone?
- Which might-have items are worth trying for?
- What assumptions need to remain true?
- When will we update the forecast?
The forecast should create a conversation about scope, priority, and risk.
Common Mistakes in Fixed-Date Agile Planning
Treating the High End as a Promise
The high end of the range is possible, not guaranteed. Do not treat the might-have area as if it were committed.
Ignoring Unknown Work
If unknown work is likely, leave room for it. Otherwise, the forecast will look safer than it is.
Skipping Product Backlog Ordering
Fixed-date planning depends on an ordered backlog. If the backlog is not ordered, the forecast cannot show which items are likely to fit.
Calling Everything Mandatory
If every item is treated as mandatory, the team has no way to make useful scope tradeoffs. Push for real ordering 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-date 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-Date Forecast
Before using a fixed-date forecast to guide stakeholder decisions, check that:
- The date is truly constrained enough to plan around.
- Scope is still negotiable, orderable, or adjustable.
- The team has counted the number of realistic sprints available.
- Velocity is represented as a range, not a single optimistic number.
- The product backlog is ordered by current priority.
- Unknown work has been considered explicitly.
- Stakeholders understand the difference between will-have, might-have, and will-not-have scope.
- 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.
Common Questions About Fixed-Date Agile Planning
What Is Fixed-Date Agile Planning?
Fixed-date agile planning is milestone planning that starts with a target date and forecasts how much scope may be completed by that date.
How Is Fixed-Date Planning Different from Fixed-Scope Planning?
Fixed-date planning answers, “How much can we deliver by this date?” Fixed-scope planning answers, “When might this set of work be done?”
What Should the Output of a Fixed-Date Plan Be?
The output should usually be a scope range: what the team will likely have, might have, and probably will not have by the target date.
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, something needs to change.
Should We Use Average Velocity?
Prefer a velocity range. A single average hides variation and can make the forecast look more certain than it is.
How Do We Handle Items in the Might-Have Area?
Treat them as possible but uncertain. Do not promise them without understanding the risk. Use them for tradeoff conversations.
How Often Should We Update the Forecast?
Update it whenever meaningful new information appears. For Scrum teams, that often means at least at the end of each sprint.
Fixed Date Planning Resources
Useful when stakeholders want more than the team can likely deliver by the fixed date.