3 ms·

I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

Consultant32452 7y ago
Depending on the PM I've found giving a confidence level on an estimate to be helpful. For example on a task I've done a million times I might estimate that it will take me 1 hour with 95% confidence. Other tasks I might estimate at 2 weeks with 50% confidence, same task 3 weeks at 85% confidence. As with all things communication, the audience matters and it's incumbent on the speaker to communicate in a way the audience can understand. So that might not work with everyone. Some of it I think is also personal confidence. If I tell someone it'll take me two weeks, I never budge unless new information becomes available. If you budge, you are welcoming being pressured/bullied into working overtime and/or delivering poor quality all the time to meet infinite demands. Also, we must accept that most customers are willing to accept lower quality/higher risk than we want to deliver. In this case what's important is to state the risks as plainly as possible and set boundaries on what you're willing to do before those risks come back at you.
- repolfx 7y ago
  I think the problem there is that the uncertainty bounds can be massive. Almost every task will have the form: "This task should take a day. But if the feature of the framework I plan to use turns out to be buggy, it might take a month. A bug is unlikely but not impossible, I handwave a guess at 10%." This sort of estimate might be reasonable, or not, depending how fractal you want to get with the backup plan of a month of tasks which themselves have wide uncertainty estimates. But it's also quite useless for planning. You end up with a Gantt chart that says "this project might take 3 months, or 5 years", which helps nobody. Hence #NoEstimates
williamdclt 7y ago
I don't think that people are good at that. I've been asked before to give a low and a high scenario, but all I can really do is to tell you how long I think it would take (I did a +/- 50% of the estimation, and explained what I did). Sometimes there's a specific uncertainty that changes radically the estimation. But remove this uncertainty and we're back at estimating and doing +/- 50%.
- mjevans 7y ago
  It's the unknown unknowns that really make estimates inaccurate. If someone were an expert in one exact thing and that's what they worked with day in and day out, then those unknowns would be small and the areas around them well defined. It is relatively easy for someone to become a maintainer of one specific thing as long as that's the only thing they're doing for a long time. Then you look at a software developer, sysadmin, anyone in the technical industries, and quite often it's not one specific thing, it's LOTS of specific things. Each with thousands, maybe millions, of human-hours in their development and the development of the things they depend upon. Every layer of hardware and software having it's own quirks and wrinkles. It's like trying to be the god of a small solar-system of interacting planets each with plate tectonics and life-forms.
gilbetron 7y ago
Beta distribution is a bit better, which is basically what you are talking about: https://www.isixsigma.com/methodology/project-management/better-project-management-through-beta-distribution/ https://www.isixsigma.com/methodology/project-management/bet...
ionforce 7y ago
That model is too complicated for tiny minds. Just tell me when it will be done, man!
kthejoker2 7y ago
Yep, PERT is what we use internally for estimating client work. https://en.m.wikipedia.org/wiki/Three-point_estimation?wprov=sfla1 https://en.m.wikipedia.org/wiki/Three-point_estimation?wprov...

Consultant32452 7y ago

Depending on the PM I've found giving a confidence level on an estimate to be helpful. For example on a task I've done a million times I might estimate that it will take me 1 hour with 95% confidence. Other tasks I might estimate at 2 weeks with 50% confidence, same task 3 weeks at 85% confidence. As with all things communication, the audience matters and it's incumbent on the speaker to communicate in a way the audience can understand. So that might not work with everyone. Some of it I think is also personal confidence. If I tell someone it'll take me two weeks, I never budge unless new information becomes available. If you budge, you are welcoming being pressured/bullied into working overtime and/or delivering poor quality all the time to meet infinite demands. Also, we must accept that most customers are willing to accept lower quality/higher risk than we want to deliver. In this case what's important is to state the risks as plainly as possible and set boundaries on what you're willing to do before those risks come back at you.

repolfx 7y ago
I think the problem there is that the uncertainty bounds can be massive. Almost every task will have the form: "This task should take a day. But if the feature of the framework I plan to use turns out to be buggy, it might take a month. A bug is unlikely but not impossible, I handwave a guess at 10%." This sort of estimate might be reasonable, or not, depending how fractal you want to get with the backup plan of a month of tasks which themselves have wide uncertainty estimates. But it's also quite useless for planning. You end up with a Gantt chart that says "this project might take 3 months, or 5 years", which helps nobody. Hence #NoEstimates

williamdclt 7y ago

I don't think that people are good at that. I've been asked before to give a low and a high scenario, but all I can really do is to tell you how long I think it would take (I did a +/- 50% of the estimation, and explained what I did). Sometimes there's a specific uncertainty that changes radically the estimation. But remove this uncertainty and we're back at estimating and doing +/- 50%.

mjevans 7y ago
It's the unknown unknowns that really make estimates inaccurate. If someone were an expert in one exact thing and that's what they worked with day in and day out, then those unknowns would be small and the areas around them well defined. It is relatively easy for someone to become a maintainer of one specific thing as long as that's the only thing they're doing for a long time. Then you look at a software developer, sysadmin, anyone in the technical industries, and quite often it's not one specific thing, it's LOTS of specific things. Each with thousands, maybe millions, of human-hours in their development and the development of the things they depend upon. Every layer of hardware and software having it's own quirks and wrinkles. It's like trying to be the god of a small solar-system of interacting planets each with plate tectonics and life-forms.

gilbetron 7y ago

Beta distribution is a bit better, which is basically what you are talking about: https://www.isixsigma.com/methodology/project-management/better-project-management-through-beta-distribution/ https://www.isixsigma.com/methodology/project-management/bet...

ionforce 7y ago

That model is too complicated for tiny minds. Just tell me when it will be done, man!

kthejoker2 7y ago

Yep, PERT is what we use internally for estimating client work. https://en.m.wikipedia.org/wiki/Three-point_estimation?wprov=sfla1 https://en.m.wikipedia.org/wiki/Three-point_estimation?wprov...