11.1 Forecasting Progress
Key Takeaways
- Burn-downs, burn-ups, cumulative flow, and similar practices can aid transparency, but they never replace empiricism or create certainty in complex work
- In complex environments, only what has already happened may be used for forward-looking decision making—past evidence, not wishful projections
- Sprint forecasts are informed by Developers’ past performance, current capacity, and the Definition of Done—not by Product Owner mandates or fixed scope contracts
- The Product Owner uses forecasts to communicate with stakeholders honestly, without presenting plans as guaranteed delivery dates or frozen commitments
- Velocity and charts support conversation and risk awareness; they are not the measure of product value or a substitute for inspecting Done Increments
11.1 Forecasting Progress
Managing products with agility requires looking ahead without pretending the future is knowable. Stakeholders ask when a Product Goal will be reachable, when a market capability will be available, and whether the next Sprint can deliver a particular outcome. Forecasting answers those questions with evidence and humility. PSPO I tests whether you treat forecasts as tools for transparency—or as false certainty that freezes the backlog and fights empiricism.
Scrum Guide 2020 (The Sprint): Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
That Guide language is high-yield. Memorize the spirit: practices are useful; empiricism is mandatory; the past is the input to the future.
Why Forecasting Matters for Product Owners
The Product Owner is accountable for maximizing product value and for effective Product Backlog management. Forecasts help the PO:
| Use of forecasts | Healthy purpose |
|---|---|
| Stakeholder communication | Set expectations about likely progress toward the Product Goal |
| Investment decisions | Help organizations decide whether to continue, pivot, or stop funding a direction |
| Ordering trade-offs | Compare options with rough effort/value signals informed by history |
| Risk transparency | Surface uncertainty instead of hiding it behind a Gantt chart |
| Sprint collaboration | Support Planning conversations without dictating Developer selection |
Forecasts do not exist to:
- Convert the Product Backlog into a fixed multi-release contract
- Let managers punish teams for missing a guessed date
- Replace inspection of Done Increments with chart cosmetics
- Give the Product Owner authority to order Developers how much work they “must” take
Empiricism First: Only What Has Already Happened
Complex product work (new features, new markets, integration risk, changing users) means what will happen is unknown. Forward-looking decisions must be grounded in what has already happened:
| Evidence from the past | How it informs a forecast |
|---|---|
| Completed Product Backlog items that met Done | Typical throughput per Sprint |
| Actual capacity (availability, skills, holidays) | Realistic Sprint load |
| Impediments that slowed delivery | Risk buffers and improvement priorities |
| Outcomes of released Increments | Whether the path toward the Product Goal still makes sense |
| Definition of Done quality bar | Whether “almost done” work was truly forecastable |
What does not count as solid forward-looking input
- A stakeholder’s hoped-for date with no historical basis
- A project plan written before the team existed
- Velocity targets imposed by management as “commitments”
- Counting work that is not Done as if it were complete
- Assuming next Sprint will magically be twice as productive without evidence
Exam trap: Choosing the answer that says charts replace empiricism, or that the team should forecast from the roadmap alone because “we planned it carefully.”
Useful Practices: Burn-Downs, Burn-Ups, Cumulative Flow
The Guide explicitly names common practices. You should know what they do and what they cannot do.
Burn-down charts
A burn-down typically shows remaining work over time (within a Sprint or across a release horizon). It answers: Are we burning remaining scope toward zero?
| Strength | Limitation |
|---|---|
| Quick visual of remaining work vs. time | Scope changes can make the chart misleading if not transparent |
| Useful inside a Sprint for the team’s plan | Does not measure value or customer outcomes |
| Encourages discussion when progress stalls | Can be gamed by inflating estimates or redefining Done |
Burn-up charts
A burn-up typically shows completed work climbing toward a scope line (or total scope that may also rise). It answers: How much have we completed, and how is total scope moving?
| Strength | Limitation |
|---|---|
| Separates “work done” from “scope changed” | Still does not prove value |
| Better for release-level transparency when backlog grows | Can encourage feature-count thinking if misused |
| Supports honest stakeholder conversation about scope creep | Future remains uncertain |
Cumulative flow diagrams (CFDs)
A cumulative flow diagram shows work items in states over time (for example, To Do, In Progress, Done). It answers: Where is work accumulating? Is flow healthy?
| Strength | Limitation |
|---|---|
| Exposes bottlenecks and WIP problems | Requires honest state transitions |
| Supports Lean-style flow improvement | Not a substitute for Sprint Goals or Product Goal |
| Complements throughput thinking | Can become dashboard theater without action |
Shared rule for all three
Proven useful, do not replace empiricism. Charts are transparency aids, not truth machines. Inspect real Increments, real outcomes, and real Done quality.
| Practice | Helps with | Never proves |
|---|---|---|
| Burn-down | Remaining work trend | Guaranteed delivery date |
| Burn-up | Done progress vs. scope | That finished work is valuable |
| Cumulative flow | Flow and bottlenecks | That the Product Goal is correct |
Sprint Forecasts: Past Performance, Capacity, Definition of Done
In Sprint Planning, Developers forecast what they can complete. That forecast is not the Product Owner’s order list of mandatory items. Guide-aligned inputs include:
1. Past performance
How much work of similar size and risk has this Scrum Team finished to Done recently? Past Sprint outcomes are evidence. New teams have less history—forecasts should be more cautious, not more theatrical.
2. Capacity
Who is available this Sprint? Skills needed? Known meetings, vacations, support load, or production incidents that reduce capacity? Capacity is real; ignoring it creates fake plans.
3. Definition of Done
Forecasts only make sense against a clear quality bar. If “Done” includes testing, documentation, integration, and compliance checks, then selecting ten items that cannot all meet Done is not a forecast—it is wishful packing. Raising the Definition of Done may temporarily reduce apparent throughput while increasing true releasability.
| Healthy Sprint forecast | Unhealthy Sprint “forecast” |
|---|---|
| Developers select work they believe they can bring to Done | PO assigns a fixed scope “you must commit” |
| Based on recent Done history and capacity | Based only on stakeholder deadline pressure |
| Accounts for DoD effort | Treats coding-complete as done |
| May adjust when new information appears (with PO collaboration on scope) | Punishes any change as “broken commitment” |
| Supports a coherent Sprint Goal | Maximizes story points with no Sprint Goal focus |
Product Owner collaboration: The PO ensures the most important Product Backlog items and Product Goal mapping are clear. Developers own how much they forecast they can complete. The Scrum Team collaborates on the Sprint Goal and plan.
Communicating Forecasts Without False Certainty
A core PSPO skill is honest forecasting language.
| False certainty (avoid) | Empirical forecast (prefer) |
|---|---|
| “We will deliver all 40 items by June 1—guaranteed.” | “Based on the last six Sprints’ Done throughput, we forecast roughly N Sprints for the current top ordered slice; that changes if scope, capacity, or Done quality shift.” |
| “Velocity is 40, so Q3 is locked.” | “Velocity helps estimate ranges; outcomes and reordering still adapt.” |
| “The release plan is a fixed contract.” | “The release plan is a forecast that we inspect and adapt.” |
| “Missed the date means the team failed Scrum.” | “Missed date is information—inspect causes, adapt backlog, process, or Goal.” |
Ranges and confidence over single-point promises
Complex work favors ranges (“likely 4–7 Sprints for this ordered set”) and assumptions (“if capacity stays similar and scope does not grow”). Single-point dates with no uncertainty language train stakeholders to treat forecasts as commitments the Scrum Team never actually made.
What stakeholders still need from the PO
Honesty is not vagueness. Stakeholders need:
- Clear Product Goal and ordered next steps
- Visible progress via Done Increments and outcomes
- Forecasts expressed as projections from evidence
- Explicit statement that the Product Backlog remains emergent
- Early signal when evidence invalidates a prior forecast
Forecasts vs. Value, Velocity, and Commitments
| Concept | Role |
|---|---|
| Forecast | Projection of progress based on past evidence |
| Velocity / throughput | Historical rate of finishing work to Done—input to forecasts, not the goal |
| Sprint Goal | Commitment of the Sprint Backlog—focus for the Sprint |
| Product Goal | Commitment of the Product Backlog—long-term product target |
| Value | Why work matters; not measured by points burned |
Exam discrimination:
- If the question asks what may be used for forward-looking decisions in complex environments → what has already happened
- If the question asks whether burn-downs replace empiricism → no
- If the question asks who forecasts Sprint capacity/selection → Developers, informed by past performance, capacity, DoD
- If the question asks whether charts guarantee dates → no
- If the question asks how PO talks to stakeholders about dates → forecasts without false certainty, inspect and adapt
Common Forecasting Traps on PSPO I
| Trap | Why it fails |
|---|---|
| “Charts replace the need to inspect Increments” | Guide: practices do not replace empiricism |
| “Future is planned in detail, so past does not matter” | Only the past may ground forward-looking decisions in complexity |
| “PO forecasts and assigns all Sprint work” | Developers forecast what they can complete |
| “Velocity is the measure of success” | Success is product value and progress toward Goals |
| “Not Done work counts in the forecast as complete” | Only Done work is a reliable Increment |
| “A forecast is a binding multi-Sprint scope contract” | Forecasts adapt; backlog remains emergent |
| “Raise pressure to raise velocity permanently” | Unsustainable pace and quality games destroy empiricism |
Practical PO Checklist for Forecasting Progress
- Keep the Product Goal and top ordered items transparent.
- Use historical Done throughput, capacity, and DoD when discussing horizons.
- Prefer burn-up/CFD/burn-down as conversation tools, not weapons.
- Never present a single date as guaranteed in complex work without evidence and caveats.
- Re-forecast when evidence changes (scope, capacity, quality, market).
- Protect Developers’ ownership of Sprint selection forecasts.
- Inspect real outcomes—not only charts—at Reviews and after releases.
Quick Self-Check
- Burn-downs, burn-ups, CFDs: useful; do not replace empiricism
- Complex environments: forward-looking decisions use what has already happened
- Sprint forecasts: past performance, capacity, Definition of Done
- Developers forecast Sprint completion; PO does not impose fake certainty
- Communicate forecasts as adaptive projections, not frozen delivery contracts
According to the Scrum Guide 2020, how should practices such as burn-downs, burn-ups, and cumulative flow be treated?
In complex environments, what may be used for forward-looking decision making under the Scrum Guide?
What best informs a Developers’ forecast of work for a Sprint?