|
|
|
|
|
by cpitman
3905 days ago
|
|
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. |
|
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)