This comment and the comment you replied to, are probably the most useful things to be read on HN in a long time. ;)

There's only one problem with that rule: This is not done to dev estimates, but to the estimate of the next lower level of management. If your project has 5 levels of management before all participants are under one umbrella, team estimates in days will lead to a project taking years.

Claiming that the organization is flat is no cheat though: Create phantom managers so that ever 6 people have a manager, and those managers have managers, until the structure has a root. 300 programmers without managers would get 50 phantom first level managers, who have 9 phantom second level managers, 2 phantom third level managers, and a single phantom project managers. If an organization has more management layers than that, they will be even slower.

Hah, this was a running a joke at my last place of work ('Double it, change the units') where we were developing for clients and so were often publishing estimates externally.

More recently they moved into the world of science and actually fed back the results of previous estimates into the estimation process, to try and address systematic mis-estimation. Yes, each estimate may not be right, but it's surprising how if you average them out you can get them pretty close.

I used to suggest this method of estimating at my previous job. People thought I was crazy. I was right every single time.

It surprises me how well this worked every time I applied it.

It stops working very well when you get to months and years planning however :(

anddd get the best date you can. If you don't get it from stakeholders, it doesn't count. Get it from stakeholders.