Ask HN: How do you do time estimates?

https://news.ycombinator.com/item?id=554364

by teej • 17 years ago

27 26 17 years ago

news.ycombinator.com

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.

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?

Comments from different industries or perspectives are appreciated. I'm of the firm belief that programmers don't know everything.

lbrandy• 17 years ago

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• 17 years ago

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• 17 years ago

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.

jdavid• 17 years ago

it sounds like what you are saying is the first estimate is the optimist in us, and until it seems 'funny' that it should take so long, you are giving it a test against the pessimist in you. as entrepreneurs, and creators we probably always 'believe' that something is doable, hence the optimism.

thomanil• 17 years ago

What he said, apart from a few differences that I've found works for me (YMMV):

1. Do ENOUGH design and requirement gathering up front. Talk to stakeholders and users. Play around with any unfamiliar technology that you're required to use. In short, get your bearings before you start estimating.

2. Extract tasks that must be done. Each task should take less than a day or two to complete - larger tasks than this are often "lumps" of work which are harder to estimate accurately. Divide as needed. Don't forget testing, bugfixing, "polish" and all that jazz!

3. Estimate each task in IDEAL hours. Ie. "how many hours would this take if I could focus 100%, no interruptions, closed office?" Another approach is to estimate entirely using relative units - go google the "Poker Planning Game".

4. Add up total ideal hours. Then multiply by a risk factor. (My absolute minimum is 20% - that's if I have a complete lock on both the technology, the requirements and ALL other significant project factors.)

5. Figure out how many IDEAL hours you actually get done each week. How much effective time do you have left when you subtract meetings, interruptions, lunch, motivation lapses, etc etc? Divide the hour number from step 4 by these actual hours accomplished each week.

6. Now you know roughly how many weeks the project will take. Then take into consideration miscelleaneous external constraints. Will Joe Developer be there week one or is he tied up? Will Sue Tester go for a three week holiday to Hawaii at some point? Tweak the schedule further based on such known specific "X factors".

7. By this point you have a rough idea of when you will be done... in an ideal world. :)

Note: This is what I do for small projects or single iterations/increments in larger projects, ie 1-3 months for a few developers. Larger processes / project scopes = different techniques. Go google Agile/Scrum/other modern development methodologies. :)

JesseAldridge2• 17 years ago

8. Realize that your estimate is ridiculously huge and anyone who sees it will think you're screwing with them.

9. Rationalize cutting it down.

10. Kick yourself as you struggle to meet impossible deadlines.

swombat• 17 years ago

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

mannicken• 17 years ago

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 +/-.

iamwil• 17 years ago

http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28...

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

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

blogimus• 17 years ago

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.

Eliezer• 17 years ago

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

JesseAldridge2• 17 years ago

Along these lines, keep a daily log of work you've done. That way you can look back and see how long stuff really takes to get done.

drsnyder• 17 years ago

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.

IsaacSchlueter• 17 years ago

While the planning fallacy is absolutely a problem, the issue is that "roughly similar" is a hard thing to gauge in software development.

Unless you're doing fairly repetitive work (cranking out brochure websites for clients, for instance), you shouldn't be doing any "roughly similar" projects! Each thing you do should be brand new—if it wasn't, you'd just reuse the code you already have.

That is the perennial dilemma in software estimation. You don't know how big it is until you're halfway done building it.

I'm not proposing a solution to this problem, just pointing out that this IS a problem, and probably not one that can be solved in a one-line bit of advice. Saying "cut it up into pieces" or "estimate similar past projects" is like telling a nervous guy to "just be himself" on a first date.

cjg• 17 years ago

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.

wallflower• 17 years ago

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.

alexk• 17 years ago

Go get

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

I would even call this book a survival guide.

utnick• 17 years ago

1) make an estimate

2) triple it

donal• 17 years ago

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.

DavidPP• 17 years ago

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

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.

Tangurena• 17 years ago

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.sysmod.com/psp.htm

noss• 17 years ago

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.

scumola• 17 years ago

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• 17 years ago

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.

papaf• 17 years ago

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• 17 years ago

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.

Ask HN: How do you do time estimates?

Related Stories