Updating and Communicating Agile Forecasts
A forecast can support an initial decision, but it becomes more useful when it is updated to reflect what the team has learned.
Good forecast communication shows what changed, why it changed, what assumptions still matter, and what decisions stakeholders need to make next.
Use this page when a team has created a milestone forecast and needs to keep it current, credible, and useful for stakeholder decisions.
Who This Page Is For
This page is for Product Owners, Scrum Masters, agile coaches, leaders, and stakeholders who need to keep milestone forecasts useful after the first forecast has been created.
It is especially useful when:
- A team needs to update a fixed-date or fixed-scope forecast
- Stakeholders want to know whether a milestone is still realistic
- Scope, velocity, assumptions, risks, or priorities have changed
- A forecast is being treated as a commitment
- Leaders need clearer forecast updates without pressuring teams into false certainty
What This Page Covers
This page explains how to update an agile milestone forecast as the team learns.
You will learn when to update a forecast, what parts of the forecast to update, how fixed-date and fixed-scope forecast updates differ, how to communicate ranges and assumptions, and how to turn forecast changes into better stakeholder decisions.
If you need the underlying forecasting inputs first, start with The Components of an Agile Forecast.
Why Forecasts Need to Change
A forecast is a prediction about the future.
That prediction should improve as the team learns more. 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.
If the forecast never changes, that may feel reassuring. But it can also be a warning sign.
A forecast that does not change despite new information is often less trustworthy, not more. It may mean the team is defending the original plan instead of using what it has learned.
Agile forecasting works best when teams treat the forecast as a living planning tool.
Forecast, Plan, and Commitment Are Different
One reason forecast conversations go badly is that people use the same words to mean different things.
A forecast is a prediction about what may happen.
A plan is what the team intends to do based on that forecast.
A commitment is what the team or organization is confident enough to promise.
Those are related, but they are not interchangeable.
For example, a team may forecast that it could complete 150 to 210 points by a fixed date. The plan might be to focus on the highest-priority 150 points and treat the next 60 as stretch or optional scope. A commitment, if one is made, should usually be smaller and safer than the optimistic end of the forecast.
Confusing these three things creates problems.
If every forecast is treated as a commitment, teams will hide uncertainty, inflate estimates, or avoid giving forecasts. If every plan is treated as a promise, normal learning starts to look like failure.
Use forecasts to support decisions. Use plans to coordinate action. Use commitments carefully.
What Should Trigger a Forecast Update?
A forecast should be updated whenever the team has meaningful new information.
For many Scrum teams, that means at least at the end of each sprint. The sprint gives the team new information about completed work, velocity, quality, scope, risks, and stakeholder priorities.
Update the forecast when:
- The team completes work
- Velocity changes
- Scope is added, removed, split, or reordered
- Unknown work becomes known
- Dependencies change
- Risks become clearer
- Team capacity changes
- Stakeholders change priorities
- The team learns that an assumption was wrong
The update does not need to be elaborate every time. Sometimes it is enough to say, “The forecast has not meaningfully changed.” Other times, the update should trigger a scope, date, or priority conversation.
What to Update in the Forecast
A useful forecast update should show more than a new date or new number.
Update the parts of the forecast that changed:
- Completed work: What moved from planned to done?
- Remaining known work: What is still visible in the product backlog?
- Unknown work: Has new work emerged? Has uncertainty decreased?
- Velocity range: Has recent team performance changed the likely range?
- Planning constraint: Is the date still fixed? Is the scope still fixed?
- Confidence: Is the team more or less confident than before?
- Tradeoffs: What decisions are now needed?
The goal is not to produce a status report full of activity. The goal is to keep the forecast useful for decisions.
Updating a Fixed-Date Forecast
A fixed-date forecast answers:
How much can we deliver by this date?
When updating a fixed-date forecast, update the scope range.
That usually means revising the will have, might have, and will not have areas of the ordered product backlog.
As each sprint finishes, some work is completed. Some work may be added. Some work may be removed. Velocity may shift. Unknown work may become known. Priorities may change.
The updated forecast should help stakeholders see:
- Which items are still likely by the date
- Which items are now at risk
- Which items should no longer be assumed for the milestone
- Whether scope tradeoffs are needed
A fixed-date forecast should not simply say, “We are on track” or “We are behind.” It should show what that means for scope.
Related topic: Fixed-Date Agile Planning
Updating a Fixed-Scope Forecast
A fixed-scope forecast answers:
When might this set of work be done?
When updating a fixed-scope forecast, update the time range.
That usually means revising the likely sprint or date range based on completed work, changed scope, updated unknown-work allowance, and current velocity range.
The updated forecast should help stakeholders see:
- Whether the completion range moved earlier or later
- What caused the change
- Whether the scope is still the same
- Which assumptions still need to hold
- What tradeoffs could improve the date range
A fixed-scope forecast should not simply say, “The date moved.” It should explain why the date range changed and what choices are available.
Related topic: Fixed-Scope Agile Planning
Communicate Ranges, Not False Precision
Forecasts are often most useful when communicated as ranges.
A single date or number can look more confident than the evidence supports. A range shows that the team understands there is uncertainty.
Instead of saying:
We will finish on June 14.
Say:
Based on our current scope and velocity range, this work is likely to finish between late May and mid-June.
Instead of saying:
We will deliver 180 points by the deadline.
Say:
By the deadline, we are likely to deliver the first 150 points in the backlog and might deliver up to 180 if things go well.
A range is not a way to avoid accountability. It is a way to communicate honestly so people can make better decisions.
Explain What Changed Since the Last Forecast
Stakeholders do not need a new forecast with no explanation.
They need to know what changed.
A good forecast update answers:
- What did we complete?
- What did we learn?
- What new work appeared?
- What scope changed?
- Did velocity change?
- Did any assumptions change?
- What does the change mean for the milestone?
For example:
Last sprint we completed 28 points and discovered about 15 points of additional integration work. Our velocity range is still 25 to 35 points, but the known scope has increased. The fixed-date forecast now shows the top 150 points as likely and the next 40 points as possible but at risk.
That kind of update gives stakeholders the information they need to decide what to do next.
State the Assumptions Behind the Forecast
A forecast is only as good as its assumptions.
Make the important assumptions visible.
Common assumptions include:
- The team remains stable
- The product backlog remains ordered by priority
- Velocity remains within the current range
- No major dependency slips
- No major production issue interrupts the team
- The amount of unknown work stays within the allowance
- Stakeholders do not add significant new scope without changing the forecast
You do not need to list every minor assumption. Focus on the assumptions that could meaningfully change the forecast.
Then revisit those assumptions when updating the forecast.
Separate News from Decisions
A forecast update often contains two different things:
- News: What changed in the forecast.
- Decisions: What stakeholders need to do about it.
Keep those separate.
For example:
News: Based on the new work discovered this sprint, the payment reporting features have moved from will-have to might-have.
Decision: We need to decide whether to simplify payment reporting, move another feature out of the milestone, or accept that payment reporting may come later.
That distinction helps stakeholders respond productively.
Without it, forecast updates can sound like vague status reporting. With it, the forecast becomes a decision tool.
Communicate Bad News Early
Bad news gets worse when it is delayed.
If a forecast shows that a date is at risk or a desired scope no longer fits, say so early. Waiting until the problem is undeniable leaves fewer options.
Early bad news gives stakeholders time to make better choices:
- Reduce scope
- Split a feature
- Simplify a workflow
- Change priority
- Move the date
- Add capacity carefully
- Accept more risk knowingly
The goal is not to make the forecast sound good. The goal is to make the forecast useful.
A team that communicates risk early may feel less comfortable in the moment, but it gives the organization a better chance to make a good decision.
Make Planning a Shared Problem
When a forecast shows that the desired scope does not fit the desired date, the team should not be left alone to “make it happen.”
Planning should become a shared problem.
The Product Owner, team, leaders, and stakeholders should work together to understand what is driving the gap and what tradeoffs are available.
Useful questions include:
- What is making this work larger than expected?
- Which parts of the scope create the most uncertainty?
- Which items are truly essential for the milestone?
- Which items could be simplified?
- Which items could move later?
- What would make the forecast more reliable?
- What can leaders or stakeholders do to help?
A forecast should not be used as a weapon against the team. It should be used to improve the conversation.
Recommended article: When Planning Should Become a Shared Problem
Ask for Truth, Not Reassurance
Leaders and stakeholders often want reassurance. That is understandable. Dates matter. Customers matter. Revenue matters.
But reassurance is not the same as truth.
If leaders ask questions that imply the desired answer, teams may feel pressure to search for a path to yes instead of explaining what is realistic.
Better questions include:
- What assumptions are we making?
- What could derail this forecast?
- Is this the optimistic case, the likely case, or the cautious case?
- What has changed since the last forecast?
- Which scope is most at risk?
- What decision do you need from us?
- Is this a forecast, a plan, or a commitment?
The way a forecast is received affects the honesty of the next forecast.
When a team brings bad news, one of the best first responses is simple:
Thanks for telling me.
That response makes it safer to keep the forecast honest.
Recommended article: Why Smart Teams Overcommit and How Leaders Make It Worse
Use a Simple Forecast Update Format
A forecast update does not need to be complicated.
A useful update can follow this pattern:
- Current forecast: What does the forecast say now?
- Change since last update: What moved and why?
- Assumptions: What must remain true?
- Risks: What could change the forecast?
- Decision needed: What should stakeholders decide now?
- Next update: When will the forecast be updated again?
For example:
Current forecast: We are likely to complete the first 150 points by the milestone and might complete up to 180.
Change since last update: The forecast range did not change, but 12 points of new work were added after the integration review.
Assumptions: The team remains stable and the new integration work does not grow further.
Risk: The reporting features are now in the might-have range.
Decision needed: Decide whether reporting is required for the milestone or can move to the next release.
Next update: We will update the forecast after the next sprint review.
That is enough for most stakeholder conversations.
Common Mistakes When Updating and Communicating Forecasts
Most forecast communication problems come from making uncertainty harder to see or decisions harder to make.
Reporting Activity Instead of Decisions
Stakeholders need to know what the forecast means for decisions, not just what the team worked on.
Hiding Changed Assumptions
If the forecast depends on assumptions, update those assumptions when they change. Do not let old assumptions silently drive a new forecast.
Treating the Forecast as a Commitment
A forecast is a prediction. A commitment is a promise. Treating them as the same thing makes teams less honest about uncertainty.
Communicating Only One Date or Number
A single date or number can create false confidence. Use ranges when the evidence supports a range.
Waiting Too Long to Share Bad News
Late bad news leaves fewer options. Communicate risk while stakeholders still have time to act.
Making the Team Own Every Tradeoff Alone
When scope, date, and uncertainty collide, planning should become a shared problem among the team, Product Owner, leaders, and stakeholders.
Defending the Original Forecast
The first forecast was based on what the team knew then. A better forecast should replace it when the team learns more.
Before You Share a Forecast Update
Use these questions to make sure the forecast update supports a useful stakeholder conversation.
- Is the current forecast shown as a range when a range is more honest than a single date or number?
- Does the update explain what changed since the last forecast?
- Are the most important assumptions visible?
- Are changed assumptions called out clearly?
- Does the update distinguish news from decisions?
- Does it identify which scope, date, or confidence tradeoffs are now needed?
- Does it make risks visible while stakeholders still have time to act?
- Does it avoid treating the forecast as a commitment unless a real commitment is being made?
- Does it make clear when the forecast will be updated again?
This is not a reporting checklist. Use it to decide whether your forecast update will help stakeholders make better decisions.
FAQ
How Often Should We Update an Agile 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.
Should Every Forecast Be a Range?
Not always, but many milestone forecasts should be communicated as ranges because scope, velocity, and unknown work can change. A range is often more honest than a single date or number.
What Should We Include in a Forecast Update?
Include the current forecast, what changed, what assumptions still matter, what risks are visible, and what decisions stakeholders need to make.
Is a Forecast the Same as a Commitment?
No. A forecast is a prediction. A plan is what the team intends to do based on that prediction. A commitment is what the team or organization is confident enough to promise.
What if Stakeholders Want One Date?
Give the clearest answer the evidence supports, but explain the risk. If a commitment is needed, make sure it includes enough margin to be credible.
What if the Forecast Gets Worse?
Communicate it early and explain why. Then move to tradeoffs: scope, date, quality, capacity, sequencing, or risk.
Who Should Communicate the Forecast?
Usually the Product Owner should be deeply involved because forecast updates affect scope, priority, and stakeholder expectations. The team should also participate when technical risks, velocity, dependencies, or feasibility need to be explained.
Communicating Forecasts Resources
Useful when a forecast shows that stakeholders want more than the team can likely deliver.
Useful for distinguishing forecast, plan, and commitment and avoiding pressure-driven overcommitment.