I was having a discussion with a project manager and they were saying that relative point estimates cannot accurately depict how much effort can fit in an iteration. I was showing them the cone of uncertainty and explaining that at the start, before we have 'detailed requirements' we may be up to 1/4th or 4x off in estimates in hours, but if we estimate items relative to eachother we'll still be "right" because we're relating them to eachother, not to 'hours'.

Let's put it another way...

how many milimeters is between these pipes

|                                                                        |

Pretty hard to guess, also, what about screen size, what about screen resolution?

Now what if i said, put a pipe in the middle of those 2 pipes. you'd probably get pretty close to the 'perfect' middle. like this:

|                                    |                                   |

So no matter how many milimeters it is from pipe 1 to pipe 2, i know that from pipe 2 to pipe 3 will be about the same! (on any screen).

Plus, if you give a developer 3 days to do something, they're going to take all 3 days (or more). In fact they might not even start until the third day being overconfident they can do it faster than 'the team' estimated it in ideal hours.

on a different note...

Stop with the Do-hicky wizzbang snake oil magic bullet sauce throwing around of 'agile'. Believe me, i tried it... it was a mistake.

Think of it more like "let's just work together, allow the customer to drive the bus, make visible to them how their changes impact the project, and deliver 'something' every couple weeks to a month".

When you stop worrying about methodology, excessive documents, project management bs, task reporting, and focus on delivering working software as a team... everything else clicks and the problems that rear their heads are obvious.