PSM I Forecasting and Release Planning: Empirical Forecasts and Releasing Value

Forecasting in Scrum is making an evidence-based estimate of when Product Backlog items might be Done, and release planning is deciding when to put Done Increments in front of users to get the most value from them. Neither one is an event, an artifact or a role in the Scrum Guide 2020. They are practices a Scrum Team chooses, and they work inside the framework's rules: empiricism, the Sprint, the Product Backlog, the Increment and the Definition of Done.

Scrum.org lists Forecasting & Release Planning as one of the competencies in its Managing Products with Agility focus area. The Guide itself gives only a few sentences that bear on it, but those sentences are precise, and they settle almost every question:

• The Sprint: Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.
• The Sprint: practices such as burn-downs, burn-ups and cumulative flows exist to forecast progress; while proven useful, they do not replace the importance of empiricism. Only what has already happened may be used for forward-looking decision making.
• Increment: multiple Increments may be created within a Sprint, an Increment may be delivered to stakeholders before the end of the Sprint, and the Sprint Review should never be considered a gate to releasing value.
• Definition of Done: work cannot be considered part of an Increment unless it meets the Definition of Done.

This lesson turns those rules into the decisions a Scrum Master and Product Owner actually face: how to build a forecast, what counts as progress, who decides when to release, what to do when a date is fixed, and which popular practices (release Sprints, Sprint 0, velocity targets) do not fit Scrum.

Scrum forecasts only from what has already happened because, in complex work, the future is unknown. The Guide says so directly: in complex environments what will happen is unknown, and only what has already happened may be used for forward-looking decision making. This is empiricism, one of Scrum's foundations, applied to planning.

In practice, the evidence for a forecast is the Done work the team has actually completed in past Sprints, together with what is left in the ordered Product Backlog. Anything that has not happened yet is a prediction or a wish, not an observation: estimates made before work began, the plan a project started with, or a number someone would like to see. Those can be compared with the evidence, but they cannot stand in for it, and pressure to agree to a date does not turn the date into evidence.

Evidence only helps if it matches current conditions. If the team recently made its Definition of Done stricter, older Sprints measured work that would not count as Done today, so a long average overstates what the team now delivers. If the team changed its Sprint length, Sprints of different lengths must be put on a common time basis before they are averaged. In both cases the old data is still evidence; it just has to be read for what it measured. Discarding it is as wrong as using it blindly.

Because new results arrive every Sprint, a forecast is never finished. Each Sprint adds evidence, and the forecast is refreshed with it.

Sprints make delivery predictable by capping how long a Scrum Team can go without inspecting and adapting its progress toward the Product Goal: at most one calendar month. Predictability in Scrum does not come from a detailed upfront plan. It comes from a short, regular loop in which real results are inspected and the plan is adapted.

Two properties of the Sprint matter for forecasting:

• One month or less. Sprints longer than a month are not Scrum. When a Sprint's horizon is too long, the Guide notes, the Sprint Goal may become invalid, complexity may rise and risk may increase. The longer the gap between inspections, the later everyone learns that the product is drifting from its goal, so the remedy for a horizon that is too long is a shorter Sprint.
• Fixed length. The Guide says Sprints are fixed-length events to create consistency. A steady cadence is what makes one Sprint's results comparable with the next. If Sprint length varied with whatever work was selected, one Sprint's results would stop being comparable with the next and forecasts drawn from them would weaken, even if every Sprint stayed within the one-month maximum.

A fixed length does not mean frozen scope: during a Sprint, scope may be clarified and renegotiated with the Product Owner as more is learned. And the Sprint's end is not a release date; releasing is decoupled from the Sprint, as the next sections show.

The Daily Scrum does not set this limit. It inspects progress toward the Sprint Goal. The Sprint Retrospective inspects how the team works. It is the Sprint, with its Sprint Review, that bounds the inspection of progress toward the Product Goal.

Burn-downs, burn-ups and cumulative flow diagrams are optional forecasting practices that the Scrum Guide mentions as examples; velocity is a complementary practice the Guide does not mention at all. None of them is required, none is an artifact, and none replaces empiricism.

Key points about these practices:

• The team chooses. The Guide mandates no forecasting technique. It assigns no owner to the charts either; keeping them is not a Scrum Master duty.
• Scrum has three artifacts: the Product Backlog, the Sprint Backlog and the Increment. A chart is not one of them.
• A chart is not inspection. However accurate a burn-up has been, it does not replace inspecting the real Increment with stakeholders at the Sprint Review, which is held every Sprint.
• The 2017 rules are gone. The 2017 Guide said the Product Owner tracks the total work remaining toward a goal at least every Sprint Review, and that the Development Team (the 2017 name for the Developers) tracks the work remaining in the Sprint Backlog at least every Daily Scrum, to project whether the Sprint Goal would be met. The 2020 Guide removed both. It prescribes no work-remaining tracking for anyone; it only notes that such practices exist and do not replace empiricism.

Velocity cannot be compared between teams because each team sizes work on its own scale, and it should never be a target because a target changes the number without changing the output. Velocity is a team's own record of how much Done work it completed per Sprint, measured in whatever units that team uses (story points are one common choice). It is useful only to that team, for forecasting its own work.

Across teams: one team's eight points are not another team's eight points. Comparing velocities to rank teams or to move work to the "fastest" team compares numbers on different scales.

As a target: when leadership demands a higher velocity, the cheapest way to meet the demand is to size items larger, or to count items before they meet the Definition of Done. Velocity goes up; working features reaching users do not. Velocity measures sized output, not value, so a rising velocity on its own says nothing about value delivered. This is the general rule that a measure stops being useful once it becomes a target.

In Scrum, the Developers size their own work (Product Backlog refinement and sizing are covered in the lesson on Product Backlog management). The Scrum Master does not size items, and does not use velocity to measure the team's performance.

Only work that meets the Definition of Done counts as progress toward a release, because only that work is part of an Increment. The Guide states that work cannot be considered part of an Increment unless it meets the Definition of Done, and that an item which does not meet it cannot be released or even presented at the Sprint Review; it returns to the Product Backlog for future consideration.

That rule removes several common shortcuts:

• No partial credit. An item that is "mostly finished" or "code complete but untested" counts as zero, not as a fraction.
• Acceptance is not Done. Product Owner acceptance or passing an item's acceptance criteria does not replace the Definition of Done; both must hold.
• Being shown is not Done. Work seen at a review is not Done because it was seen.
• Quality is not a lever. The Definition of Done is a commitment. Relaxing it "for small changes" or "just until the release" means undone work is released as if it were complete.

When undone work is counted as complete, every forecast built on it is wrong immediately, not later. Any progress chart that includes undone items overstates progress and hides the remaining work. The same happens when work needed for release sits outside the Definition of Done: it stays invisible in the team's progress until late, and the forecast misses it. The Scrum response is to strengthen the Definition of Done over time so each Increment includes that work. The Developers conform to the Definition of Done, and the Sprint Retrospective is where the team inspects and improves it. (The Definition of Done itself is covered in the lesson on Scrum artifacts.)

A Done Increment must be usable. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. That is why an Increment does not need a later step to be tested together with others.

An Increment can be released whenever it is Done and releasing it adds value, including before the Sprint ends, and deciding when to release is a value decision that belongs to the Product Owner's accountability. The Guide says multiple Increments may be created within a Sprint, an Increment may be delivered to stakeholders prior to the end of the Sprint, and the Sprint Review should never be considered a gate to releasing value.

Done is not the same as released. Holding a Done Increment back for a while and releasing it at once can both be sound choices, depending on where the value lies; the Guide requires the Increment to be usable, and it leaves the timing to the person accountable for maximizing value. Earlier release usually means earlier value and earlier evidence for adapting the Product Backlog. It does not remove the Sprint Review (the sum of the Increments is still presented there), the Sprint Goal or the Definition of Done.

Who decides. The Product Owner is accountable for maximizing the value of the product, so release timing sits with that accountability. The Developers make the Increment Done; the Scrum Master serves the team and makes no product decisions; stakeholders influence the Product Owner but do not decide. The 2020 Guide does not say in so many words that "the Product Owner decides when to release". This follows from the value accountability, and Scrum.org's forecasting and release planning guidance frames it the same way.

Delegation. The Guide says the Product Owner may do the Product Backlog work or may delegate the responsibility to others, and remains accountable either way. By the same reasoning, a Product Owner may delegate release timing to others while staying accountable. Delegation does not change what makes work releasable: meeting the Definition of Done, not anyone's approval.

Continuous delivery. A team deploying several times a day still works in Sprints. Frequent releases change when value reaches users, not whether the team inspects and adapts progress toward the Product Goal each Sprint. The Daily Scrum is not a release-approval meeting.

No. The Scrum Guide 2020 defines no release planning event, no release plan artifact, and no special kind of Sprint such as a release, hardening, stabilization or "Sprint 0". Scrum has five events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective) and three artifacts, and every Sprint aims to produce at least one usable Increment that meets the Definition of Done.

• Release or hardening Sprints. A Sprint used only to stabilize and deploy work means the earlier Sprints did not produce Done Increments. Wrapping it in Scrum's events does not change that. Needing one is a symptom: the Definition of Done is not sufficient, and the fix is to strengthen it, not to schedule the undone work for later.
• Integration Sprints. The same applies when several teams integrate only before a release. Each Increment is already meant to be integrated with all prior Increments.
• Sprint 0. A planning-only Sprint to produce a release plan and an architecture, with no Increment, is not Scrum. A team needs only enough of an emerging Product Backlog to start; planning and design happen inside Sprints as the work emerges, and the first Sprint already aims for a usable Increment.
• Release planning meetings. Teams may forecast in any way that helps, but nothing in the Guide makes this a formal event, for one team or many. Forecasts are revised whenever new evidence arrives; the natural place to discuss them with stakeholders is the Sprint Review.
• A 12-month Sprint-by-Sprint plan. Sprint Backlogs are created at each Sprint Planning by the Developers, and Product Backlog items gain detail through refinement over time. Full upfront estimation of the backlog is not required. The Guide offers frequent inspection and adaptation as the source of predictability instead.

With a fixed date, scope is what flexes: the Product Owner orders the Product Backlog so the most valuable items become Done first, makes the forecast and its uncertainty transparent early, and releases what is Done on the date. Quality (the Definition of Done) and the Sprint length are not levers.

Effort is not a hidden lever either. Sustained extra hours or a final catch-up period leave the evidence unchanged and tend to cost quality, so they postpone the conversation rather than resolve it. When an agreement fixes both scope and date and the evidence shows they cannot both be met, the time to raise it is when the evidence appears.

The underlying idea: a forecast that shows a gap is not a failure but information. Empiricism only helps if that information is made transparent while there is still time to act on it.

Release forecasts are revisited every Sprint, and the Sprint Review is where progress toward the Product Goal is discussed with stakeholders and the Product Backlog is adapted. The Guide says that at the Sprint Review the Scrum Team presents the results of its work to key stakeholders, progress toward the Product Goal is discussed, and attendees collaborate on what to do next; it is a working session, and the team should avoid limiting it to a presentation.

A forecast is not a commitment. Scrum's commitments are the Product Goal (for the Product Backlog), the Sprint Goal (for the Sprint Backlog) and the Definition of Done (for the Increment). A shared forecast does not bind the Developers, and holding it fixed after the Product Backlog changes makes it misleading. When new information changes priorities, the Product Owner adapts the Product Backlog and the forecast follows it.

Use a range, refreshed each Sprint. An honest empirical forecast shows the spread the team has actually demonstrated. To build one, divide the remaining work by the high and the low end of recent throughput: with 90 items left and recent Sprints finishing 9 to 15 Done items, the range is 90 ÷ 15 to 90 ÷ 9, or 6 to 10 Sprints. The width of the range is information: it shows stakeholders how much uncertainty the evidence contains. And because the inputs change every Sprint, the range must be recalculated every Sprint to stay empirical.

Several teams, one product. When multiple Scrum Teams build one product, they share one Product Goal, one Product Backlog and one Product Owner, and they must mutually define and comply with the same Definition of Done. A release forecast therefore covers the one Product Backlog and counts only work integrated into an Increment that meets the shared Definition of Done. Progress that is not integrated and Done across all teams is not progress toward the release.