[jacques_chester]

I worked on an estimation tool[1] inspired by PERT 3-point estimates for a while, simply because there weren't any when I went looking one time.

It was a lot of fun reading up on the estimation literature in various disciplines. Personally I think that the real magic of PERT 3-point estimation is the "unpacking effect" -- making people think about the subtasks of a headline issue.

When I'm in situations where I point a story, I like to ensure that we engineers say aloud what assumptions we're pointing on ("Bootstrap will make responsive mobile almost free") and then a quick low-detail breakdown of expected tasks ("new page, new RESTful endpoint, new model code").

I find that the latter, in particular, makes a big difference in how pointing goes.

[1] http://confidest.com

[cpitman]

The other part of 3 part estimates that I like is that it forces everyone to consider the worse case. What can go wrong? What risks are there to this task? And only then do we talk about how long we think it will probably take.

The problem I have always had afterwards is communicating the results. Most people I've worked with cannot intuitively grasp confidence levels (90% vs 95% vs ...). They also invariably want a break down of how long each task or group of tasks will take so that they can negotiate down the estimate, not understanding that the total estimate is not a simple sum of each task. I'd love to hear better ways of explaining/using these sorts of estimates.

The first time was my fault: I left the columns that had intermediate values visible. One of those was the variance in each estimate, which is just the Std Dev squared. The numbers were big. No one could stop talking about how big the numbers were. No one knew what a variance was, nor appreciated that it was just the number in the previous column, multiplied by itself. Learned the very important lesson that you hide all your work, no one gets it.

[jacques_chester]

Culture, really. Trust.

Where I work, Engineering owns the estimates. No ifs, buts or maybes. We own estimates. Product managers have unlimited ability to reprioritise, but we and we alone get to say how hard it's going to be.

That said, another secret is: use story points. They are dimensionless units that are only meaningful within a single project. As soon as you give dollars or days, everybody has an opinion or an agenda.

But if you use points and project based on velocity, it's hard to negotiate. Because you're not negotiating. Those are the actual numbers. The actual historical data, staring you in the face.

(Edited for clarity)

[mistermann]

> One of those was the variance in each estimate, which is just the Std Dev squared. The numbers were big. No one could stop talking about how big the numbers were. No one knew what a variance was, nor appreciated that it was just the number in the previous column, multiplied by itself.

Just out of curiosity, were any of them interested in learning the answers to these mysteries?

[cpitman]

I spent a while trying to explain the purpose behind the numbers when it came up, but no, it really just kept coming back to the variance numbers being big. Not "why is the estimate for this so uncertain?", but more "Why is this number 100000? That's big".

This was actually not a time estimate. We were estimating the footprint for our production deployment for a very complicated distributed system. Most of the pieces were only in early development and the load model itself was uncertain by orders of magnitude.

It's a situation where statistics is easily applied, if you know statistics. If you don't, you'll never even realize it would have helped and keep saying that math is useless outside of school.