

Ask HN: How do you do time estimates? - teej

I've been a web developer for 3 years now, just starting to get a hang of the standard flow of a 9-5 job.  I'm getting a firm grasp on the technology, scope, and implications of the work I do.<p>One thing I have trouble with is doing time estimates.  How do you do time estimates now?  Did you start with something different to get to where you are now?<p>Comments from different industries or perspectives are appreciated.  I'm of the firm belief that programmers don't know everything.
======
lbrandy
1\. Write a list of the things you need to do. Be detailed. The more detail,
the better.

2\. Estimate how long you think each will take, knowing it always takes longer
than you think.

3\. Realize it always takes longer than you think, and revise your list.

4\. Double everything.

5\. Round up.

6\. Add it all up, walk to towards your bosses office and/or call the client.

7\. In a last second panic realization that it always takes longer than you
think, double it again.

In all seriousness, you will get better over time, namely after you do this
many times. The only "secret" to the process is write down a detailed list of
the things that must get done. Alot of people tend to clump up alot of the
endgame details as "polishing" and that results in the 90/10 rule taking full
effect (that the last 10% of the work takes 90% of the time) because things
like UI testing, inserting the logo, doing the install script, etc, etc, take
forever and a day.

~~~
ynniv
At the risk of being a metoo, it should be emphasized that things need to be
doubled. I'm not sure why, but I constantly find that things take twice as
long as I expect, even after accounting for the fact that things need to be
doubled.

It sometimes helps to keep doubling it until it seems funny that it could take
so long, and then step back once. ie, "Writing a parser will take a week. Two
weeks. Four weeks... weeeeell, probably not four weeks - two weeks it is."

I also like to front-load things that I'm uncertain about, as playing catch-up
near your deadline is easier when you have (hopefully over-estimated) well
known tasks remaining.

~~~
thalur
I think the doubling comes from the fact that initial estimates are always
that it would take x weeks if you were to work flat out 100% of the time. As
this is incredibly unlikely to happen, you have to increase the estimate to
take into account "overheads" (such as posting here...). I like your "double
until it's silly then go back a step" idea; it seems like a good way to get
quick estimates.

I try to take into account how accurate my estimates will be: if a sub-task is
something I've done alot, I stick with my estimate; if it's something where I
think there's a risk of it going wrong I add more time (keeping a note of the
estimate and the risk time separately - it makes project managers think you
know what you're doing!). I then add them all up, divide by 0.7 (roughly how
efficiently I convert booked hours into directly worked hours - the rest is
email and meetings etc.). Also, any task where you have to write code that
works with someone else's code, I double the estimate.

------
Eliezer
Ask how long _roughly_ similar projects in the past have taken. Do not do
_any_ specific thinking about the detailed implementation. I'm serious!

<http://www.overcomingbias.com/2007/09/planning-fallac.html>

~~~
drsnyder
I'm beginning to agree with this more and more. Consider something you have
done in the past that is similar to the the task at hand and use how long it
took as a guide.

It also helps if your development cycles are fairly short (i.e. 1-2 weeks and
no longer). I have found that it is much easier to estimate how long it will
take if the amount of work you are estimating is smaller.

Keeping your development cycles short also has the beneficial side effect of
reducing the shock factor when you have to double it.

------
blogimus
I've worked for startups and for aerospace and defense contractors. There are
of course different ways to approach software project estimation.

I've worked on projects where we needed to do details work breakdown
structures: <http://en.wikipedia.org/wiki/Work_breakdown_structure>

And I've been in environments where I had to wing it with ever changing
requirements where everything was all over the map.

Somewhere in the middle is the happy ground.

For perspective, I recommend reading the following book:

Software Estimation: Demystifying the Black Art by Steve McConnel
(<http://www.stevemcconnell.com/est.htm>)

[Edit] Estimation is an iterative process both within a project (even if you
are stuck in a god-awful waterfall) and with consecutive projects. You self
train your estimation skills for doing similar work. Its when you hit
something new that you don't have the past performance to draw upon that you
really have to rely on your instincts. As a bottom line, I'm much less wrong
when I go with my gut instincts than when I analyze and estimate ad nauseum.

------
iamwil
[http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28...](http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2839075)

<http://www.joelonsoftware.com/articles/fog0000000245.html>

<http://www.joelonsoftware.com/items/2007/10/26.html>

------
DavidPP
Sorry, I don't have time to write a detailed answer but here are couple of
interesting things to know about software estimation (from a book I have at
home but forgot the name) :

* For a known task, developer are usually too optmistic by about 30%

* At the very beginning of a project, your estimation can be off by as much as 400%, by the time you have the UI done (at least in wireframe), your estimation can be off by around 25%.

Also, I suggest reading the "Three points estimation" part of this article :
[http://www.projects.ed.ac.uk/methodologies/Full_Software_Pro...](http://www.projects.ed.ac.uk/methodologies/Full_Software_Project_Template/EstimationGuidelines.shtml)

It's usually for "big" project, but the Three points estimation technique can
be used even if you are by yourself. Also, it's more scientific than just
"doubling" your number (check Standard Deviation on wikipedia if you want to
understand how it work).

Finally, with this technique, it's easy to spot tasks which have alot of
uncertainty.

------
noss
Software engineering here:

Divide the project into smaller pices. If your estimate for a piece is more
than a day, it is still too big.

To make sure you know what is involved in implementing a piece by always
including how to perform a function-test of the piece. This is powerful for
those pie-in-the sky estimates that go "Ohh, that cant be so difficult..."

When it comes to fixing small bugs, verifying bugfixes, or other repetitive
work, collect historic and use the average time, and multiply it with the
number of things to do.

With this approach, I typically manage to time-estimate well enough for a 3
week sprint.

I have also began using a burn-down chart where I input number of hours worked
on the project each day, so in the chart i can see how my remaining time burns
down, and on top of that how many hours i did work each day. Making the
remaining time bars black and the hours-spent fire-yellow, it is a really
pretty "burn down" chart. If the fire is as big as the estimate decrease, im
spot on with my estimates.

------
mannicken
Very carefully. Never ever plan a block over 8 hours, usually between 2 and 6.
And practice. It's not something you can learn easily, you have to adapt for
your own brain.

People say they double their estimates, but I find it no longer necessary, I
usually hit the time 1 hour +/-.

------
swombat
Have a read through this article for a simplified take on Function Point
Analysis, which is the industry standard for estimation in larger projects:

<http://inter-sections.net/2007/11/10/easy-estimates>

------
wallflower
In earlier performance reviews, I was always called to task for my reluctance
to commit to a number of hours for a task. Nowadays, I give better numbers and
hedge my numbers by asking for multiple tasks at once (so I can triage and
switch among them as needed, simmer and return). I don't like it when
developers are micro-managed (and my managers understand that - e.g. they know
I'll get it done and know they can't dictate it).

In my most recent 1.0 release with was done with Scrum and Sprints, what we
observed happening was that overallocated time (tasks that did not need 6 days
but took 2 days) was reallocated to tasks that needed much more time (10 days
instead of 5 days). We were fortunate to usually meet our backlog for the
Sprint (sometimes, more complicated tasks carried over) - but in practice, it
seems that we had a fixed amount of time and the time estimates merely did a
initial slice-up (which was not accurate). We hit the (pushed by 3 months)
release deadline - however there was a fair amount of overtime.

So, if I had a lesson - the moral of the story is - time estimates are nice
but being all-in and committed to getting a product out the door is more
important.

------
Tangurena
I keep trying to apply PSP, but I find I get distracted so much that I'm
unable to keep track of my metrics and how close I come to estimates (mostly,
my boss pulls a time estimate out of his butt).

One of the key elements of PSP is to record what you do each day in a little
diary. One of the biggest ways you can improve your estimation skills is:

1 - make estimates

2 - keep track of how close those estimates came to reality

3 - compare what you did right/wrong so you can do less of the wrong and more
of the right.

<http://en.wikipedia.org/wiki/Personal_Software_Process>

[http://www.amazon.com/Discipline-Software-Engineering-
SEI/dp...](http://www.amazon.com/Discipline-Software-Engineering-
SEI/dp/0201546108/)

<http://www.sysmod.com/psp.htm>

------
donal
You aren't alone. If I had access to the book for my Project Management class,
then I could give you exact stats for how terrible most estimates prove to be.
The numbers are astounding (the studies are dated, but still adequately
horrifying).

Even doubling your estimates is unlikely to have any real reflection on
reality.

One standard methodology is called three-point estimation:
<http://en.wikipedia.org/wiki/Three-point_estimation>

How far do you want to go though? You could look up COCOMO-II, I saw someone
mention function-point analysis, then you could do monte carlo simulation...

The best way is to compare the task to previous similar tasks, but the trick
is making sure that tasks are really similar enough to make an accurate
comparison.

------
cjg
On one project I worked on, we divided all feature requests into small,
medium, large and huge (expected to be roughly 2, 5, 10, 20 days worth of
effort respectively). This allowed us to come up with a quick overall costing
of the project before starting - the estimates were gradually refined as we
learned more about the system we were building. Looking back over the project,
once most of the features were implemented, we could see that we had mostly
underestimated the small features (they took maybe 3 or 4 days) and mostly
overestimated the large or huge features.

------
alexk
Go get

<http://www.microsoft.com/learning/en/us/books/2425.aspx>

I would even call this book a survival guide.

------
papaf
The most accurate method I've used is "1 week per page". This is for backend
development and not web design.

Surely such an overly simple estimate is going to be wrong? Well yes, but
reality is complex and no calculation is going to capture it correctly.

If you find 1 week per page is too inaccurate you can update your future
estimates based on past performance.

------
Edinburger
Actual time taken to complete tasks is a good input to future estimates for
similar work.

Agile folks have the concept of 'velocity' which helps them to predict
delivery dates based on accuracy of previous estimates.

------
scumola
Make a realistic (some what conservative) estimate and triple it. Same rule
goes for cost estimates. Doubling is never enough. Better to under-promise and
over-deliver than the other way around.

------
grinich
Nobody ever complains when you finish a project under the estimated time. In
fact, it looks good even if it's only by a few hours.

------
utnick
1) make an estimate

2) triple it

