Agile Estimating vs Predictive Estimating
A steering group is shown two forecasts on the same programme. The transition workstream has a schedule with dates against every activity. The automation squad has a chart showing how much work it has been completing per fortnight and how much remains. Somebody asks which of the two is more reliable, and the honest answer is that they are reliable about different things, in different conditions, and the question of which to trust is really a question about how knowable the work is.
Both are forecasting systems. Section 2.3 of the PMBOK® Guide Eighth Edition is concerned with producing schedule information that people can act on, and neither system holds a monopoly on that. What separates them is where they look for their accuracy.
What each system measures
Predictive estimating works in absolute units. Each activity gets an effort or duration figure, built from experience, historical data, a parametric model or the judgement of somebody who has done it before. Those figures are aggregated through the logic of the network into a date, and the discipline that keeps them honest is the quality of the definition underneath them: a well-specified activity can be estimated by anybody competent, and a vague one cannot be estimated at all.
Relative estimating works in comparisons. An item is sized against other items the same team has already done, in a unit that means nothing outside that team, and the absolute rate is not estimated at all. It is observed afterwards, from how much the team actually completes per cycle, and the forecast comes from combining the sizes with the observed rate. The team is never asked how long something will take, which is the question people are worst at answering.
Where the accuracy comes from
Definition quality, on the predictive side. An absolute estimate is only as good as the description of the work being estimated, which is why predictive estimating performs well on work that has been done before and specified properly, and performs badly on genuine novelty. The failure mode is confident precision: a number carried to two decimal places, built on an activity description that three people would interpret differently.
Recent comparable history, on the relative side. Sizing by comparison needs something to compare with, so a team in its first few cycles is producing sizes with no calibration behind them, and its early forecasts should be treated accordingly. The same applies after a change of team, technology or problem domain: the unit quietly changes meaning and nobody announces it.
Feedback interval, on both sides. The real difference in practice is how often the estimate meets reality. A predictive schedule may be tested at a milestone months away; a relative forecast is tested every cycle. Shorter feedback does not make an individual estimate better, and it does make the forecast converge sooner, which matters far more to whoever has to make a decision from it.
One transition, two estimating systems
A shared services centre was taking on forty finance processes from three European sites, and at the same time a small squad was building automation for the highest-volume of them. The transition itself ran predictively, with a schedule of knowledge transfer, parallel running and cutover for each process. The automation squad worked in fortnightly cycles with relative sizing.
Both were appropriate. Transition work was well understood: the centre had migrated over two hundred processes and knew that a process of a given complexity took roughly six weeks of knowledge transfer and four weeks of parallel running. That is exactly the condition in which absolute estimating earns its reputation, and the dates held to within about a week across the programme.
The automation work was not like that at all. Nobody knew how many of the exceptions in each process could be handled without a human, and the only way to find out was to build one and see. Estimating those items in days would have produced numbers with no information in them. Sizing them against each other and watching the completion rate produced a forecast that was hopeless in cycle two and quite good by cycle six.
The friction was entirely at the steering group. The programme director asked, reasonably, for one plan, and what he was given for two months was a schedule with the automation work inserted as five activities with invented durations. Those durations were wrong every month, and the honest forecast sitting in the squad's own chart never reached the room.
What resolved it was presenting both without forcing them into one shape. The transition schedule kept its dates. The automation work was reported as a range: at the rate of the last four cycles, the remaining scope completes between these two months, and here is what changes the answer. The director's response was that he could work with a range, and that he would rather have an honest one than a date he had learned not to believe.
Running both on one programme
Put the boundary where the knowability changes. Contracted, regulated, physically committed or previously delivered work is usually estimated well in absolute terms. Discovery, integration with something poorly understood, and anything whose scope depends on what is found are better handled relatively, with the forecast rebuilt each cycle.
Report them in their own units. Converting a relative forecast into a date and presenting it beside genuine schedule dates loses the uncertainty that was the useful part of it, and gives a governance group a false sense of a single coherent plan. A range with its assumptions stated sits perfectly well next to a set of dates, provided somebody explains once why the two look different.
For a PMP® candidate, the point to hold is that both approaches are estimating under uncertainty and differ in where their reliability comes from, so a scenario contrasting them is asking how knowable that particular work is. A response that standardises everything onto one method has answered an organisational preference and not the question in front of it. A structured PMP exam preparation course takes on situations where two estimating systems have to coexist and report into the same governance.
This check needs nothing you do not already have. Take your current estimates and ask, for each significant area, what the estimate is actually based on: a description somebody wrote, a comparable job the team has recently finished, or somebody's sense of how long it ought to take. The third category is where the surprises come from, and it is usually larger than anybody expects.
Interested in going further?
Most estimating arguments are really arguments about how much is known, conducted in the language of method. Omega's PMP® Exam Preparation works through forecasting in predictive, adaptive and mixed programmes.
Estimating and forecasting in both styles are covered in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A116: Story Points Are Not Hours
A121: When a Schedule Baseline Needs to Change
A120: Schedule Compression: Fast Tracking vs Crashing
A117: Velocity: Useful Planning Aid or Dangerous Target?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
