A Metric Signal Is Not Yet a Release Decision
Delivery metrics can trigger investigation. They cannot identify the cause or choose the scope, date, cost or risk response on their own.
A release forecast becomes dangerous when its assumptions change but its authority survives. Give each version an evidence window, decision range and explicit recalculation trigger.
Standfirst: A release forecast can be honest when created and misleading a month later. Its evidence, scope and team context have changed while the coloured plan still looks authoritative. Attach an expiry condition so new evidence forces a new decision rather than a quiet date change.
A release plan is presented on Monday. Green items are treated as safe, amber items as negotiable and red items as out of reach. Three weeks later, a specialist leaves, the backlog is reordered and client testing becomes a queue. The colours remain.
The failure is not that the first forecast was imperfect. The failure is that it had no visible condition for losing authority.
A delivery rate answers a bounded question: what finished during a defined period, under a defined way of counting? It does not reveal what an altered team will finish against a different mix of work.
Record the observation window behind the forecast: dates, number of observations, team composition, work type, start and finish definitions, and exceptional events. The Kanban Guide defines throughput as the number of work items finished per unit of time. It also defines a service level expectation as a forecast with an elapsed-time period and probability, based on historical cycle time or initially a best guess. It does not prescribe velocity, a normal distribution or a universal sample size.
One commercial training course we reviewed recommends using an average and standard deviation to turn nine Sprint velocities into optimistic and pessimistic rates. That is too confident. NIST’s statistical handbook describes approximately 95.45% within two standard deviations as a property of a normal population. Its interval guidance requires distributional assumptions to be checked and distinguishes intervals for a population parameter from prediction intervals for a future observation. Nine delivery observations do not establish those assumptions or calibrated future coverage by themselves.
Use an observed range or an appropriate forecasting method whose assumptions the team can defend. Label a best guess as a best guess. More mathematics does not repair unrepresentative data.
A useful release view connects ordered work to more than one plausible delivery outcome. It then asks the decision-maker which constraint dominates now: date, available investment or minimum scope.
Do not translate that into “green means guaranteed” and “red means impossible”. Historical performance does not create certainty. Use language such as:
The labels describe a relationship between backlog order, delivery evidence and a constraint. They do not predict the fate of an individual item. If leaders need a probability, the analysis must actually produce and explain one.
The US GAO Cost Estimating Guide calls for documented assumptions, sensitivity and risk analysis, and updates using actual costs. Its principal context is programme cost estimating, so the lightweight record proposed here is an inference, not GAO’s method.
Every consequential release forecast should carry four control fields:
The expiry condition may be the next Sprint Review, the next fortnightly planning review, a material change in team capacity, a backlog reorder, a new work type, or performance outside the assumptions used. A routine checkpoint is useful even when nothing dramatic happens because it forces the plan to meet actual delivery again.
The Scrum Guide says a Sprint Review inspects the outcome and determines future adaptations. It also says that knowledge of past performance, upcoming capacity and the Definition of Done supports Sprint forecasting. Scrum does not define a release plan or require this four-field record.
This is an iterative control loop: each forecast is a version with a stated basis, not an editable claim that was somehow always current. Keep prior versions. When the range moves, record whether scope, capacity, cost, workflow or the evidence window changed.
Recalculation without consequence becomes reporting theatre. When a forecast expires, the product manager or project manager should bring the changed evidence to the person who owns the constraint.
If the date is fixed, reorder or reduce scope and state the outcome trade-off. If investment is capped, expose what falls outside the current range. If minimum scope is fixed, show the resulting date and cost range. Adding people is a scenario to test, not instant evidence of a higher delivery rate.
An adaptive approach changes the next decision in response to evidence. It does not merely redraw the same traffic lights. The plan should also stay distinct from the work board: the forecast supports a release-level choice, while the board shows the current state and exposes queues.
This method is disproportionate for a small, reversible change with no meaningful date or funding consequence. It also cannot rescue inconsistent definitions of finished, incomparable work items or a delivery system undergoing constant structural change. In those cases, improve the evidence before increasing forecast precision.
The managerial test is not “Did the team hit the old number?” It is “Did the forecast declare when it stopped being a reasonable basis for the decision?” If the answer is no, the plan did not become wrong when circumstances changed. It became ungoverned.
Research and corrections note: This article began as an editorial review of commercial training-course transcripts and was checked against the official sources linked above. The course’s automatic 95% interpretation of two standard deviations, guarantees implied by traffic-light colours, and unsupported claims that simple guessing beats capacity planning were removed or corrected. Submit corrections through the Strategica Institute contact form against SDR-180.
Written inbyStrategica Editorial DeskInstitutional Editorial & Research Deskinagileforecastinggovernance
Share this article:
Delivery metrics can trigger investigation. They cannot identify the cause or choose the scope, date, cost or risk response on their own.
Evaluate an AI project-management tool as a proposed workflow: define the job, baseline, representative tests, data and authority boundaries, human review, and scale-or-stop decision before comparing features.
A project stop decision should compare remaining value, risk, strategic fit, opportunity cost, and exit consequences—not use irrecoverable spend as the reason to keep investing.