PERT: https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
Barry Boehm's recent work:
http://www.amazon.com/Incremental-Commitment-Spiral-Model-Pr...
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.
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.
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)
Just out of curiosity, were any of them interested in learning the answers to these mysteries?
