Seriously, we developers tend to be over optimistic about how much it will take us to develop something. I have read about a simple formula.
Total Time = Developer Estimate x 10, what do you think? What is yours?
Developer productivity estimates shouldn't be measured in time, they should be measured in focus.<p>I find out when they really need it by and tell them they can have it by then. Unless it's impossible, which it almost never is.<p>The part I like to negotiate is how much focus I'll be given and which are the features that might have to be compromised because they'd add a disproportionate amount of time or complexity relative to their value.<p>By "focus," I mean that a "month" is meaningless because it might mean that I truly have a full month or it might mean that 3-5 times a week I'll be expected to stop and fix, maintain, or sit in meetings for other projects.<p>So I'd rather not tell someone that I can do something in a day. Then they expect they can have it in a calendar day, which I can't promise because any given calendar day might be full of interruptions. I'd rather tell them they can have it in a week (unless they need it sooner) and I'll worry about finding which day over the next week is the one that's most likely to be productive.<p>If they really need it in a day, it's more important that no one bother me for the next 8 business hours than whether the work is "objectively" 7 hours or 8 hours or 9 hours.
The x10 formula doesn't work :)<p>For things that really work, see:<p>- <a href="http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning" rel="nofollow">http://www.mountaingoatsoftware.com/books/1-agile-estimating...</a><p>- <a href="http://www.mountaingoatsoftware.com/articles-estimating" rel="nofollow">http://www.mountaingoatsoftware.com/articles-estimating</a><p>- <a href="http://planningpoker.com/" rel="nofollow">http://planningpoker.com/</a><p>I use these together with mind-mapping and acunote.com to estimate my projects (and it works fairly well).
Poorly! Of course, every developer/team estimates poorly without a lot of practice.<p>One of the biggest suggestions that has helped me create more accurate estimates: don't say that a feature/task is going to take N hours. Instead, give it a bounded rank. I use {1, 2, 4, 8, 16}. Total the rank.<p>That won't be helpful in the beginning, but the real win comes when you've done several projects, and you know how long 40 points will take.<p>I think most people are poor estimators on unbounded spaces, and this solves that problem.
I do it like this - works well for medium-sized projects.<p><a href="http://www.exratione.com/2010/12/a-count-and-multiplier-method-of-estimating-web-development-time.php" rel="nofollow">http://www.exratione.com/2010/12/a-count-and-multiplier-meth...</a>