Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What process do you use to estimate how long a (significant) programming task will take. Do you use one or more of the following:

  • intuition/guessing
  • reference to similar tasks whose estimated/actual lengths you recorded
  • reference to the lengths of similar task others recorded
  • saying it will take the length of time allocated for it (by your manager)

migration rejected from Aug 6 '13 at 13:51

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, MichaelT, Florian Margaine, Dynamic Aug 6 '13 at 13:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

This is an interesting question, one that I would definately like to follow due to my level of experience (or lack of!)

For me, as a relative n00b, I tend to think about my task and break it down into the series of smallest tasks possible. This then allows me to get a better handle of the tasks at hand..

Some of these tasks I may be uber-confident in, and have estimates as small as 15 mins, while others I may have no idea and book a half or whole day out to research it.

While most of the time I over-estimate (better to be safe than sorry right?) My estimation is slowly improving.

Joel Spolsky did a great piece on estimating. He also did an in-depth post on Evidence-based scheduling which basically says "over/under estimating is fine, so long as you are consistent with it".

My boss knows I will probably finish early, but he always knows I don't commit to a deadline I cannot meet. So if I ask for time, he tends to accept my estimates without too much persuading. Maybe I am lucky.

I do feel however I need to be better at estimation. I would like to knock together a little app or something to perhaps emulate Joel's idea(s).

That app is called Fogbugz :) – Daniel Cassidy Dec 3 '08 at 18:00

Good estimates take some time. If somebody wants an estimate now, let them know you'll get back to them. It's better to give them a better estimate later and make them squirm a bit now, than give them what they want, and fail to deliver because you failed at estimating.

Break the task down into smaller tasks. Large tasks cannot be estimated effectively. If you are measuring these tasks in days, break them down further. Tasks should be measured in hours (and no, don't just measure in hours...if a task will take more than 16 hours, think about it some more and split it up).

Compare to previous similar situations.

Use some of that programmer intuition, without being arrogant or optimistic about your abilities and give a buffer for potential problems (analyze potential problems and try to come up with estimates 'if this happens').

Always give a range: 10 hours +/- 2

Avoid compromising your estimate. If a manager says that's too long, don't just reduce your estimate for the same amount of work. Compromise: if they want it sooner, they'll have to cut scope or similar.

Take into account vacation of people you might have to work with if possible if the main task is a big one.

Practice. Even if you don't need to give an estimate to anybody, estimate for yourself, and see how accurate you were. Try to find out why you were off if you were.

Seconding the tip about getting back to people with estimates - I find I always underestimate when talking to someone, so I've made it personal policy not to do so. – Daniel Von Fange Mar 23 '09 at 20:38
+1 for Avoid compromising your estimate. – user Jul 28 '12 at 3:41

It's worth mentioning with breaking down tasks that the more finely detailed your estimates get, the more time you estimate for the whole project.

This can lead to some scary differences between your initial back of the envelope calculation, and your very detailed estimate based on really understanding the problem in hand.

Of course, it should go without saying that the longer estimate is usually more accurate.

It's also really important not to forget the customer's role in all of this...

We are almost obsessional (and sometimes we seem to be in a tiny minority here) about doing what we said we would by the time we said we would. But I've lost count of the number of times that it's the customer who holds things up.

I love using parts of agile methodologies in our projects, but it's a rare (commercial) customer who will play their full part in the project. Many customers want fire and forget. When it comes to making design decisions, or providing basic information about their business, or signing off on things, or paying on time, or ordering hosting or... you find they've taken an extended 2 month break in the Carribean.

You have two choices - you can either factor this in, or make clear from the start that they have a role to play too and if they don't meet their obligations the deadline may well have to move.

As for actually using your lovingly crafted application in the future (and I'm mainly talking web based CMS / e-commerce type applications here), they usually haven't allocated staff to it and expect the fairies to step in and help out...

Cynic, moi?

  • Break it down into as many small tasks as possible.
  • Put a best guessagainst each one (i.e. most accurate, if everything goes well)

The next step depends on whether you have traditional BDUF or Agile

  • BDUF: multiply every estimate to get a figure that you're 95% sure you can be done by. That way you won't fail to hit targets.

  • Agile: stick to your best guess, but update it every day that you work on a task so that it gets more and more accurate as you get closer to finishing.

Something I rant about all the time (inc on my blog) is that all estimates are only ever guesses (even when good).

By all means use them in planning but when they're used as absolutes they get inflated and gamed, every time.

the second option is what's called the "windows file copy dialog" ;) – RCIX Jan 27 '10 at 1:48