Forecasts, flow, and release choices | PSPO II: value, experiments, and product strategy

Concept and mechanism

A forecast depends on scope, capacity, and flow conditions. Throughput history may inform an estimate but does not make the date guaranteed. If new items arrive or work types change, revisit assumptions before extrapolating. Define measurement start and finish boundaries. A service-level expectation linking duration with probability is not automatically a contractual SLA or a promise for each item. In the eight-day, 85% example, some historical items took longer. Excluding those items to make the forecast look better distorts information. Communicate what the data support and what remains uncertain.

Guided application

Also consider external conditions. A code-completion date differs from the date users can benefit if an approval or transition remains pending. Expose that dependency and coordinate the decision. Technical deployment may also precede exposure: an installed but invisible capability does not yet provide usage evidence. When choosing a release, seek a useful slice meeting quality and operational conditions. Reduced scope can enable feedback, but incomplete fragments from every area do not become useful by covering more headings. Make later scope explicit and evaluate whether learning justifies the selected sequence.

IN PRACTICE

With 24 items and a recent average of six per week, four weeks is a conditional extrapolation; it does not resolve an external approval with no timing.

Common pitfalls

Average as contract; code ready as usage; SLE as individual guarantee; deployment as benefit evidence.

Related topics: EBM and measurement interpretation · Portfolio, investment, and the product operating model

Take this idea with you

A useful forecast shows conditions, uncertainty, and the decision it supports.

Create account

Reference: The Kanban Guide · PSPO II; Scrum Guide November 2020 and EBM Guide May 2024; no public numbered exam revision