estimate, predict, forecast
We are often asked, as engineers, to give estimates for how long a piece of work will take to complete or the complexity of the work.
This is not a post about the philosophical point on if we should estimate. This post proposes a change in the way we think, to help make estimates easier and more useful for everyone.
what are estimates?
An estimate is:
To calculate approximately (the amount, extent, magnitude, position, or value of something).
To form an opinion about; evaluate.
If we first skip over the fact that most of our engineering estimates are guess-timates, and are not actually “calculated”, we get a feel for what an estimate is from this definition. An estimate is an approximate or uncertain ‘amount’ of something (often time or complexity).
If we get a little more specific when thinking about estimates, we can split estimates into two categories;
Predictions
A prediction is a statement about what you think will happen in the future. It contains what and when. For example; “It will rain tomorrow at 8am.”
Forecasts
A forecast is a probabilistic statement that captures the chance of some event happening. We have ‘weather forecasts’ and not ‘weather predictions’ because there’s a level of uncertainty that must be captured. Weather forecasts are expressed as “40% chance of rain tomorrow at 8am.”
stop making engineering predictions
Our estimates tend to take the form of predictions. We give a single complexity indication, or a single deadline for completion.
By giving predictions, we fail to encapsulate the uncertainty that’s inherent in an estimate. Predictions carry an implicit sense of certainty, because they do not explicitly capture our uncertainty.
start making engineering forecasts
Predictions are too easy to disprove. If I say it will rain at 8am tomorrow at it rains at 8:30am, my prediction is wrong. If I forecast it will rain between 8am and 9am (i.e. 100% chance of rain between 8am and 9am), not only is the statement accurate, but it’s much more useful for someone else who consumes this information.
Given the forecast, I know to take an umbrella. Using the prediction, I might choose to stay inside until 8:15am and end up getting wet 15mins later.
If we apply this to engineering, our stakeholder management becomes much easier if we can express our uncertainty in probabilistic terms, and empower our stakeholders to make decisions based on the inherent uncertainty.
We can learn from the weather forecasters, and turn our “estimates” into “forecasts”.
For making time-based estimates (e.g. completion), we should think in terms of;
- chance of success (expressed as a probability, or percentage)
- window of success (expressed as a time frame)
e.g. 80% chance we complete the work in 1.5 to 2 weeks.
With this example, the wider the window of success the larger that chance of success. It is important to remember that when we are pushed to complete work on a tighter time-schedule, our chance of success will go down.
We might choose to express the same estimate as: 5% chance we complete the work in 1 week or less.
For making complexity based estimates (e.g. difficulty of work), we should think in terms of;
- a range of complexity scores
e.g. 3 to 5 complexity points
learn that nothing is certain
We should learn, and internalise, the fact that nothing is certain. There are too many variables to control for when trying to make a certain prediction. And the further out in time, the harder it is to control for all the variables.
Instead, we should learn to make forecasts that express our probabilistic thinking to control for the uncertainty.
Make forecasts and not predictions.