Ask HN: How do you calculate Development time?
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?
5 comments
Developer productivity estimates shouldn't be measured in time, they should be measured in focus.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
For things that really work, see:
- http://www.mountaingoatsoftware.com/books/1-agile-estimating...
- http://www.mountaingoatsoftware.com/articles-estimating
- http://planningpoker.com/
I use these together with mind-mapping and acunote.com to estimate my projects (and it works fairly well).
For things that really work, see:
- http://www.mountaingoatsoftware.com/books/1-agile-estimating...
- http://www.mountaingoatsoftware.com/articles-estimating
- http://planningpoker.com/
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.
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.
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.
I think most people are poor estimators on unbounded spaces, and this solves that problem.
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.
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.
I think most people are poor estimators on unbounded spaces, and this solves that problem.
My heuristic is developer estimate x 2 + 2 weeks for anything of substance, just based on my own experience and managing others.
I do it like this - works well for medium-sized projects.
http://www.exratione.com/2010/12/a-count-and-multiplier-meth...
http://www.exratione.com/2010/12/a-count-and-multiplier-meth...