7.4 Forecasting and Release Planning

Empirical Forecasting

A core PSM I trap is assuming Scrum requires estimation techniques, velocity, or burn-down charts. It does not. The 2020 Scrum Guide describes a forecast as exactly that — a forecast — and deliberately removes any mandated estimation method (the 2017 Guide's example metrics like burn-downs were dropped in 2020 to keep the framework minimal).

Quick Answer: Scrum uses empiricism to forecast. The Scrum Guide mandates no estimation technique (no story points, no hours). Velocity, burn-downs, and burn-ups are optional, useful practices — not Scrum rules. A forecast is a projection from real data, never a guarantee.

Hard Scrum Guide rules

• The Product Backlog is refined and items are sized; the Developers who will do the work are responsible for the sizing. The Guide does not say how to size.
• The Sprint Backlog includes a plan (the how) for delivering the Increment that meets the Sprint Goal; the Developers create and own this plan and update it throughout the Sprint as they learn.
• A Sprint Goal provides flexibility on scope: the scope may be clarified and renegotiated with the Product Owner as more is learned during the Sprint. This is the mechanism that keeps a Sprint valuable even when the original item list turns out to be wrong.
• Forecasting is empirical — based on observed past performance and current reality, not on a wish, a deadline, or a guarantee. Empirical delivery means the team delivers a Done, usable Increment each Sprint and lets that evidence — not a plan on paper — drive what happens next.

Optional Practices vs. Scrum Rules

The following are widely used professional practices that support Scrum but are not in the Scrum Guide. Knowing this distinction is directly and repeatedly tested — when an option says "Scrum requires X," check whether X is in the list below.

Release Planning Under Uncertainty

Because requirements and conditions change, a release plan is a living forecast, refined every Sprint as empirical data accumulates. Sound professional approaches include:

• Forecast a range (optimistic / likely / pessimistic), not a single false-precision date.
• Re-forecast after every Sprint using actual completed, Done work — real throughput, not aspirational throughput.
• Use the Sprint Goal to renegotiate scope rather than break the Sprint, extend it, or cancel quality.
• Treat early dates as hypotheses to validate, consistent with empiricism, and make the current forecast transparent to stakeholders.

Common exam traps

1. "Scrum requires story points." False — Scrum mandates no estimation unit. Sizing is required; the method is the team's choice.
2. "Velocity is a Scrum metric you must report." False — it is optional practice.
3. "A forecast is a commitment." A forecast is not a guarantee; scope can be clarified and renegotiated.
4. "To hit a date, extend the Sprint." Sprints have a fixed length and are never extended; you adjust scope, not the timebox.

Sizing, the Sprint Backlog Plan, and Empirical Delivery

It is worth being precise about what the Scrum Guide does require around forecasting, because the exam rewards candidates who keep the line in the right place.

• Sizing is required; the method is not. Product Backlog items must be sized, and the Developers who will do the work are responsible for that sizing. Whether they use story points, t-shirt sizes, ideal days, item counts, or simply judgment is entirely their choice — Scrum is silent on it.
• The Sprint Backlog contains a plan. The Sprint Backlog is the Sprint Goal (why), the set of items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). The Developers own and continually update this plan as they learn during the Sprint; it is highly visible and emergent, not a fixed Gantt chart frozen at Sprint Planning.
• Empirical delivery means a Done Increment. The mechanism that makes any forecast trustworthy is that the team produces a usable, Done Increment that meets the Definition of Done at least once per Sprint. Real, integrated, valuable increments are the evidence forecasting projects from. A burn-up of "almost done" work is fiction; only Done work counts.

How scope, time, and the Sprint Goal interact

When a Sprint runs into surprises, the team has a clear hierarchy of what may move and what may not:

This is the empirical answer to deadline pressure: protect the timebox and quality, keep the Sprint Goal as the anchor, and renegotiate scope. Stakeholders get an honest, continuously re-derived forecast instead of a comforting but false guarantee — which is exactly what "managing products with agility" means in practice.