

Ask HN: How do you calculate Development time? - mobl

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?
======
gdulli
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.

------
thibaut_barrere
The x10 formula doesn't work :)

For things that really work, see:

\- [http://www.mountaingoatsoftware.com/books/1-agile-
estimating...](http://www.mountaingoatsoftware.com/books/1-agile-estimating-
and-planning)

\- <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).

------
owenmarshall
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.

------
mpd
My heuristic is developer estimate x 2 + 2 weeks for anything of substance,
just based on my own experience and managing others.

------
exratione
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-method-of-
estimating-web-development-time.php)

