It addresses how to aggregate multiple PERT estimates at the task level into a PERT estimate for a larger item.

For estimating X trips, there are a few answers, depending on how you’re asking the question. If you’re wondering what type of “estimation learning” to bake into your estimates, I’d be inclined to say “none.” While you will get better at estimating as time goes on, you also have increased uncertainty the further you look into the future. Your ability to accurately predict 15/30/60 right now is higher than to predict 15/30/60 six months from now. I don’t know which factor will dominate, so I’d be inclined to ignore both factors, assuming that they cancel each other out.

Also, what’s the math for estimating X trips to the store? If 1 trip is PERT:15/30/60, then what will 15 trips be?

Thanks for commenting on this estimation article too. Now all you need to do is join the conversation on our use-case-points estimation series :).

That formula for a PERT estimate is interesting – it biases the pessimistic numbers. Essentially, instead of saying “this is what we think it should be” with a beta distribution, it hides the “we think we’re wrong” part within the math.

I suspect that you lose the ability to quantify the probability of delivering at a point in time when you do this. I prefer to use the “pure” PERT estimate of 1+4+1, where I know the math works. Then, I recognize that my calculation of the standard deviation is also correct. When I want to be conservative, I project the PERT estimate plus two standard deviations.

This is, in my opinion, a better approach, because it is more transparent, and easier to follow during a review. It doesn’t “pollute” the original PERT number by baking the conservative view into the original numbers.

(optimistic + (3 * likely) + (pessimistic*2)) / 6
Source: Estimating Software- Intensive Systems

I think that we should use PERT to estimate workitems, but not the core of the project. it means you can estimate meetings, documentation, general task, etc.