Managers and project managers should get some training in how to manipulate estimates with uncertainty values attached. There are simple rules for this, but they’re not always intuitive.
Independent. Not valid for most software projects.
And the relative uncertainties are Small. Not true for most software projects.
And the distribution of uncertainty is symmetrical. Also not true.
Conversely, the only thing in his favour is the Central Limit Theorem works remarkable rapidly (for independent variables with finite variance).
That said, you can build up a model and use monte carlo methods to get the resulting spread in uncertainty.
He is right about the dismal lack of calibration of estimates, but worse than that is the disastrous failure to update estimates daily as new information comes in (eg. story just done blew out by factor of two).
Hidden in all this are two immutables…. the Deadline and The Scope. If nobody is going to flex on that and insist that the original estimates must hold…. Guess what? The quality implodes and technical debt explodes.
And the velocity for subsequent projects slows and slows.
I agree that linking to those uncertainty rules was misleading. I should have given that some more thought. I still think that you can get good calibrated estimates in the face of interdependencies, but it’s true that the rules I linked to are not meant for that.
It’s much easier to pour on pressure, juggle teams and scope, “manage expectations”, sacrifice quality, incur technical debt with zero intent of repaying…. than to estimate properly.
No. No. No.
With a link to http://web.uvic.ca/~jalexndr/192UncertRules.pdf
Those formula assume the uncertainty is…
Conversely, the only thing in his favour is the Central Limit Theorem works remarkable rapidly (for independent variables with finite variance).
That said, you can build up a model and use monte carlo methods to get the resulting spread in uncertainty.
He is right about the dismal lack of calibration of estimates, but worse than that is the disastrous failure to update estimates daily as new information comes in (eg. story just done blew out by factor of two).
Hidden in all this are two immutables…. the Deadline and The Scope. If nobody is going to flex on that and insist that the original estimates must hold…. Guess what? The quality implodes and technical debt explodes.
And the velocity for subsequent projects slows and slows.
I wrote the article. Thanks for the feedback!
I agree that linking to those uncertainty rules was misleading. I should have given that some more thought. I still think that you can get good calibrated estimates in the face of interdependencies, but it’s true that the rules I linked to are not meant for that.
I’m pretty sure there are some off the shelf tools to do this sort of modelling.
Guess what?
I haven’t heard of anybody in the industry using them.
Not a single blogger is ranting about how wonderful these tools are.
Why on earth would someone not use a tool that works for estimating the probability distribution of the outcome?
Because estimates have no value.
The PHB’s simply don’t actually care about the answer.
Michael O’ Church has the answer why.
It’s much easier to pour on pressure, juggle teams and scope, “manage expectations”, sacrifice quality, incur technical debt with zero intent of repaying…. than to estimate properly.
The payoffs for project managers are perverse.