Forecasting and Release Planning

What it is

In complex work, the future cannot be predicted precisely, so Scrum relies on empiricism for planning. Forecasts of progress toward the Product Goal use what has actually happened, and value is released whenever an Increment is usable rather than waiting for a fixed release phase.

How it works

Forecasting

• The Scrum Guide notes that 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.
• Progress toward the Product Goal is discussed at the Sprint Review, where the forecast can be inspected and adapted.

None of these practices is required by Scrum.

Forecasts are not promises

A forecast is a likely range based on past evidence, and it changes as the team learns. At Sprint Planning the Developers select the items they expect to complete; the commitment for the Sprint Backlog is the Sprint Goal, not every selected item.

A worked example: the team has completed between 18 and 24 points of work per Sprint over the last five Sprints, and about 120 points remain for the next release goal. A reasonable forecast is roughly five to seven Sprints, revisited at every Sprint Review as scope and evidence change. Stating "exactly five Sprints, guaranteed" ignores empiricism.

Releasing value

• An Increment must be usable, and it may be delivered to stakeholders before the end of the Sprint.
• The Sprint Review should never be considered a gate to releasing value.
• Multiple Increments may be created within a Sprint.
• Only work that meets the Definition of Done can be released.
• Each Sprint aims at a usable Increment, so releases follow value and feedback, not a fixed release phase. Scrum.org guidance treats the release decision as part of the Product Owner's accountability for value; the Scrum Guide itself does not say who decides.

No special Sprints

Scrum has no release Sprint, hardening Sprint or stabilization Sprint. All work necessary to achieve the Product Goal, including quality and release work, happens within Sprints, and every Increment must meet the Definition of Done.

How the exam asks about this

• "Do burn-down charts replace empiricism?" No.
• "What may be used for forward-looking decisions?" Only what has already happened.
• "Can an Increment be released before the Sprint Review?" Yes.
• "The team wants a hardening Sprint before release. What does Scrum say?" There is no such Sprint; every Increment must meet the Definition of Done.