3 ms·

One technique is to ask for 3 point estimates. Get everyone involved to estimate each item in three different ways: 1. How long it will take if everything goe

by RegW 5y ago

One technique is to ask for 3 point estimates. Get everyone involved to estimate each item in three different ways: 1. How long it will take if everything goes well and according to plan. 2. How long it will take if everything goes wrong and we uncover further problems along the way. Probably getting those risks listed. 3. How long it is likely to take. I imagine we tend towards doing just one of the first two, but having to do both should lead to more agreement on the third. That said - its been about 30 years since I was taught this as part of critical path analysis, and I've never seen it used in the wild.

wpietri 5y ago
For sure. I know plenty of ways to deliver solid estimates and hit dates. I think the problem is execs mostly prefer having estimates they like over accurate estimates.
regularfry 5y ago
The problem even with that method is that if everyone agrees on "most likely", and that is perfectly correct, and you use it, you'll still be wrong more often than right. The reason is the underlying distribution: because the probability distribution is usually heavily skewed to the left, with a long tail to the right and lots more room for things to extend than to contract, the day which is "most likely" when looked at in isolation is actually well to the left of the median date, the date with a 50% probability of being before or after completion. If you want an 80% chance of being right, say, you need to do some more maths with the three numbers to figure out what the right date to use is. I would very much like to see this done. The problem is that estimation isn't seen as work. It's seen (or, more accurately, framed) as something devs should be able to just magic from thin air with perfect accuracy, so why would we bother adding complexity? Very few organisations bother tracking estimation precision, I think because the incentives are aligned such that it's actually to the advantage of the people writing the cheques that developers under-estimate. I think the power over the developers that a missed estimate gives to an adjacent organisation is a real factor in ensuring this never gets improved.
- drdec 5y ago
  > you need to do some more maths with the three numbers to figure out what the right date to use is. We did this all the time at a previous job. We had a spreadsheet in which we put in the three estimates. They were combined in some ratio (I think it was 1 part each for the outliers and 2 parts for the most likely). Then some time was added on for testing, test remediation and project management at a set additional percentage. Worked out pretty well, we seldom ended up with issues when using this method.
  - regularfry 5y ago
    Tom DeMarco describes a method in Waltzing With Bears that's quite interesting: use a triangle defined by the three points as a rough approximation for the probability distribution, and then cumulative distribution function calculations are just juggling quadratics that you can plug into Excel. Mind you, these days Excel's got the distribution function formulae in it that you'd need to do it "properly" with a lognormal distribution, but I like the way the three estimation points have a direct and obvious link to the result with the triangle method.

by RegW 5y ago

wpietri 5y ago

For sure. I know plenty of ways to deliver solid estimates and hit dates. I think the problem is execs mostly prefer having estimates they like over accurate estimates.

regularfry 5y ago

The problem even with that method is that if everyone agrees on "most likely", and that is perfectly correct, and you use it, you'll still be wrong more often than right. The reason is the underlying distribution: because the probability distribution is usually heavily skewed to the left, with a long tail to the right and lots more room for things to extend than to contract, the day which is "most likely" when looked at in isolation is actually well to the left of the median date, the date with a 50% probability of being before or after completion. If you want an 80% chance of being right, say, you need to do some more maths with the three numbers to figure out what the right date to use is. I would very much like to see this done. The problem is that estimation isn't seen as work. It's seen (or, more accurately, framed) as something devs should be able to just magic from thin air with perfect accuracy, so why would we bother adding complexity? Very few organisations bother tracking estimation precision, I think because the incentives are aligned such that it's actually to the advantage of the people writing the cheques that developers under-estimate. I think the power over the developers that a missed estimate gives to an adjacent organisation is a real factor in ensuring this never gets improved.

drdec 5y ago
> you need to do some more maths with the three numbers to figure out what the right date to use is. We did this all the time at a previous job. We had a spreadsheet in which we put in the three estimates. They were combined in some ratio (I think it was 1 part each for the outliers and 2 parts for the most likely). Then some time was added on for testing, test remediation and project management at a set additional percentage. Worked out pretty well, we seldom ended up with issues when using this method.
- regularfry 5y ago
  Tom DeMarco describes a method in Waltzing With Bears that's quite interesting: use a triangle defined by the three points as a rough approximation for the probability distribution, and then cumulative distribution function calculations are just juggling quadratics that you can plug into Excel. Mind you, these days Excel's got the distribution function formulae in it that you'd need to do it "properly" with a lognormal distribution, but I like the way the three estimation points have a direct and obvious link to the result with the triangle method.