Thanks for writing and sharing your thoughts.
“Ranged estimates” are an integral part of many processes that use estimates, and have been in use for many decades. However, IMO they’re essentially the same thing as an estimate. 1/
An estimate is typically given as an approximation, as in “it will take about 3 months give or take 2 weeks” 2/
There is also the “confidence level” or “confidence interval”, which is often seen in conjunction with the range. 3/
Add to this the idea that we must frequently revisit our estimate (and it’s range and confidence interval) is an indication that they might merely be a mechanism to make us feel we are actively managing risk. 4/
IMO ranged estimates and confidence intervals add no meaningful value when attempting to predict the time or cost of software development, or in helping us make good decisions. 5/
You also shared the idea that the estimation process is an opportunity to have a discussion about the work at hand. Some say that the estimates themselves are not the main purpose of estimating. I often hear this. 6/
This implies that a side effect of the process is the reason for doing the estimates. However it is my opinion and experience that the conversation can just as easily be had without the estimates. 7/
That is, that doing estimates for the side effect is not necessary and a waste if we can simply have the conversation anyway. 8/
IMO estimation is fraught with problems, and we are only scratching the surface here. IMO estimates are ill-suited to inform the decisions we count on them to inform 9/
In other words, the sort of decisions that drive us to want estimates and predictions are where the interesting conversation lives. 10/
Estimates can be an indicator of more deeply rooted issues. Not always, but in some cases.
Of course we need estimates if we follow a process that requires estimates! But maybe we can find other ways of going about our work. 11/
Of course we need estimates if we follow a process that requires estimates! But maybe we can find other ways of going about our work. 11/
One area of interest to me is the prevalence of managing software development as a project. 12/
There has been a great deal of research and writing about the ways we fool ourselves so we can have a feeling of certainty and control. 13/
The desire to control things, and the belief that we can control things (there are many biases and fallacies related to this), leads us to conclude that we can manage software development if have a mechanism and process that allows us to predict the future. 14/
There are other ways to work, and many of us have found we can manage software development without estimates. I question the need for estimates, and suggest we benefit from exploring and trying other approaches to managing software development. 15/
By working in a lean and agile manner we can manage software development without estimating or otherwise attempting to predict the future. Perhaps most orgs are not yet able to do so, and maybe they never will be, but some are.16/
To move beyond estimates and the project mindset we must be willing to consider that many of the things we firmly believe are not worthy of that belief. Is it possible we have been fooling ourselves? This is not an easy thing for most of us, including myself. 17/
“Fear of losing control is a big barrier for change. Although much control is only an illusion of control, the fear is real” ~@bbogsnes 18/18
