Rolling Wave Estimation

Goal

Rolling wave estimation makes estimation a recurring act: each completed delivery supplies measured costs and effort that replace the kickoff assumptions in the estimate of everything that remains. Scrum is the familiar instance: the sprint review inspects what was delivered and adjusts the product backlog, then the next sprint is planned on that revised state. Progress is followed on a burndown or a cumulative flow diagram, which carry the work remaining against the time axis.

The technique answers a limit of planning: the far work depends on lessons execution has not yet delivered, and the team's real productivity on this product stays unknown for as long as it has delivered nothing. The decision it supports is a budget commitment made while part of the work is still poorly known, and it makes that commitment defensible by dating its correction. The deliverable is a layered estimation plan, one row per delivery carrying its horizon, its level of detail, its method and its amount, reissued at the end of each delivery beside the actuals of the previous one. It arranges the other methods of the estimation family over time.

Usage

When to use it

• Delivery by iterations or releases: the end of each delivery is a revision point already on the calendar.
• Team productivity unknown: only the first completed delivery measures it.
• Little visibility beyond the current delivery: the late work depends on results the first deliveries have not yet produced.
• Multi-year programme: a fine estimate of the late work would be obsolete before it was used.
• Overall figure expected now: definitive on the imminent delivery, an acknowledged rough order of magnitude on the rest.

When not to use it

• Scope fully known and stable: price the whole breakdown once with bottom-up estimation rather than defer it.
• A single short deliverable: there is no following delivery to correct, a rough order of magnitude is enough.
• A firm total demanded at the start: price the whole scope up front with parametric estimation and accept the cost.

Description

The loop: estimate, deliver, measure, revise

The imminent delivery is broken down into work packages, priced in detail, then executed. The actuals are recorded: costs incurred, effort consumed, scope put into service, departures from the planned packages. Comparing them with the preceding estimate gives a variance. That variance revises two things: the estimate of the next delivery, which moves from rough order of magnitude to definitive because it is now decomposed, and the rough orders of magnitude of the deliveries still far off. The measured variance tells you about the capacity of the team and the difficulty of the product, two factors that hold for all the work ahead.

Accidental variance or structural variance

Before a variance is applied to the rest of the plan, you have to know whether it is accidental or structural. An accident will not recur: an infrastructure outage, the prolonged absence of a specialist, a package added by an outside decision. Its cause being closed, the variance stays inside the delivery where it arose. A structural variance rests on something that holds for all the remaining work: the productivity of the team, the unit cost of a profile, the effort of taking over a legacy system every delivery will have to cross, a rate of scope discovery higher than the breakdown anticipated. That one propagates: the revision applies it to the estimates that remain.

Magnitude is the first clue: a variance that exceeds the accuracy band announced for a definitive estimate, about ten percent, signals an estimation bias rather than a hazard inside the band. Repetition is the second: the same variance with the same sign over two consecutive deliveries is structural, whatever cause is ascribed to it.

The detail gradient

The level of detail decreases with distance in time. The imminent delivery receives a definitive estimate, produced by decomposing then summing the work, which the BABOK places at ten percent of variance or less. Each later delivery is held at a rough order of magnitude, a single number which the BABOK notes often does not exceed fifty percent of variance on either side. The gradient moves one delivery at each revision.

From planning package to work package

The far work rests as a planning package, an element of the work breakdown structure left above the executable level: that is the form progressive elaboration takes in rolling wave estimation. It carries only a rough order of magnitude, for want of a fine enough decomposition. As its execution approaches, it is broken into work packages and then activities, and it can then receive a definitive estimate. Only what has first been finely decomposed is finely priced, and only what execution is approaching is finely decomposed.

The actuals of the completed delivery come into this step too: they supply the unit costs and the effort per package type that correct the costing of the new breakdown. Two routes give the same result, pricing that breakdown at the observed costs or pricing it at the old ones then applying the measured variance to it. Doing both counts the variance twice.

A method that composes others

Each delivery receives the estimation method its horizon warrants, which makes rolling wave estimation a scheduling of methods over time. The technique supplies no formula: it decides which one to apply and when. The near delivery is built by bottom-up estimation over work packages or by PERT where a three-value interval is wanted. The far deliveries fall to the rough order of magnitude or to top-down estimation, a high-level split of a total, or even to parametric estimation where a calibrated model exists. Expert disagreement on either horizon is settled by the Delphi method, whose converged value feeds the plan. The rough order of magnitude answers "what accuracy, for lack of information"; rolling wave estimation answers "when to replace that rough order of magnitude with a definitive estimate and on which measured data". The actuals recalibrate the methods themselves as well: they update the coefficients of a parametric model and the unit costs of a bottom-up estimate.

The pitfalls

Treating the rough order of magnitude of a far delivery as a firm commitment is the costliest mistake. It is provisional by construction and must be presented as such, failing which the first upward revision, the technique working normally, will be read as an overrun. The second mistake is to deliver without measuring: with no costs and effort recorded per delivery, there are no actuals to feed back, and the layered plan becomes a breakdown that nothing corrects. The third is to attribute every variance to a single non-reproducible cause, which exempts the next estimate from any correction and carries the same bias forward delivery after delivery. The fourth is to detail too far ahead: breaking out still-distant deliveries consumes work that the measurements of the intervening deliveries will render moot.

AI considerations

Artificial intelligence shortens the comparison between the planned and the actuals, a repetitive and documented operation. At the end of a delivery, an assistant connected to time tracking, to the project ledger and to the ticket manager computes the variance as a percentage per work package, aggregates it by task type and flags the items that depart most from the average. It then proposes a revised costing of the next delivery from the observed unit costs, together with rough orders of magnitude recalculated for the rest of the scope. Those values come out of the records. They can be checked line by line. It also keeps the layered plan up to date: it breaks a planning package into work packages, keeps the successive states and flags the far deliveries whose assumptions have moved.

Three things escape it. The first is the qualification of the variance: saying that an overrun is structural presupposes knowing whether its cause will recur, which calls for a knowledge of the context that tracking data does not carry. A model that mechanically applies the variance of the first delivery to everything else turns an accident into a trend. The second is the breakdown itself, where a delivery stops and how far to detail: a model asked to elaborate the plan will detail the far work and produce the false precision the technique sets aside. The third is the holding of the revision, an organisational discipline a model prepares without being able to guarantee it.

Examples

A health insurer replaces its policy-management platform, in three releases over eighteen months. At kickoff, only release 1 is broken down into work packages and priced by bottom-up estimation; the other two are held at rough orders of magnitude.

State A, at kickoff

Release 1 goes into service in month 6 for CHF 552'000. The variance is CHF 72'000, 15 % above the estimate, and it exceeds the top of the announced band, CHF 528'000, by CHF 24'000. An overrun outside the band signals an estimation bias: the analysis traces it to the unit costs of the team, 15 % higher than those used for the initial costing, across every package type. Nothing indicates they will come down: the variance is qualified as structural, which authorises applying the 15 % to the rest of the scope.

State B, at the end of release 1

A single mechanism produces state B: the measured unit costs, 15 % higher, apply to everything not yet delivered. Release 2 is broken down into work packages and priced at those costs, which gives CHF 690'000. Its breakdown revealed no scope the rough order of magnitude did not already carry, so the move to a definitive estimate tightens the band from ±50 % to ±10 % with no other effect on the amount. Release 3 keeps its single block: CHF 500'000 multiplied by 1.15 gives CHF 575'000. The envelope goes from CHF 1'580'000 to CHF 1'817'000, 15 % more, since the same rate bears on all three rows.

One measured delivery moves the centre of the interval without tightening it. The tightening of release 3 will come from its breakdown, at the end of release 2.

Visualisations

The timeline shows the same calendar in two snapshots: fine dense blocks on the decomposed delivery, single blocks on the ones that follow, the detail having advanced one delivery after the first went into service. It is the same plan: the same scope, re-estimated with what the first delivery measured.

Cost

Tools

The project-planning tool is the support for the technique, because it carries the work breakdown structure and its levels: a planning package stays undecomposed there until its execution approaches, and the tool propagates durations and costs through the calendar at each revision. The value depends on what it does with the actuals: a tool that records the budget to date, the actuals and the estimate at completion per package gives the variance without manual calculation.

A spreadsheet is enough for a plan of a few deliveries, one row per delivery and one column per attribute, provided the successive states are kept there: the comparison between what was estimated and what was delivered feeds the next revision and an overwrite removes it. Agile backlog-management tools suit the case where the deliveries coincide with the releases or the increments: the near is refined at the level of items ready for development, the far stays as coarsely sized epics and the throughput measured over the completed sprints plays the role of the actuals fed back.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.19 Estimation: the placement of rolling wave estimation among the estimation methods, the principle that estimation is an iterative process whose values are reviewed and revised as information becomes available, the construction of the technique from a rough order of magnitude on the remaining work and a definitive estimate on the imminent iteration or phase, both refined at the end of each, together with the accuracy bands, about fifty percent for the rough order of magnitude and ten percent or less for the definitive estimate. The BABOK describes these methods and prescribes none.
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), rolling wave planning: the canonical definition of the technique as a form of progressive elaboration, the near work planned in detail and the far work at a higher level, together with the gradual decomposition of the planning package into work packages then activities as execution approaches, in the Define Activities process.