Take the 2-minute tour ×

We, as programmers, are constantly being asked 'How long will it take'?

And you know, the situation is almost always like this:

  • The requirements are unclear. Nobody has done an in depth analysis of all the implications.
  • The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.
  • You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.
  • The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?
  • No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Many of these are organizational or cultural issues that are not simple and easy to solve, but in the end the reality is that you are being asked for an estimate and they expect you to give a reasonable answer. It's part of your job. You cannot simply say: I don't know.

As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does.

What is your personal process for deciding and delivering an estimate? What techniques have you found useful?

share|improve this question
If the requirements are not so clear, you can estimate with a 50% error margin (wider range). If the requirements are clear, you can estimate with a 20% error margin. Another good strategy that worked for me is to split a project into stages. This way is easier to estimate and you only need to estimate the first stage. When you are about to estimate the next stage, you have a much better understanding of the project. Also, trust between you and your contractor should be better. I also always write my assumptions and preconditions. Never write "it will work on IE8 or higher", be specific. –  Francisco Goldenstein Jun 10 '14 at 14:13
Sergio, "As a result, I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again. But it does." How much do you feel improved today? –  r.pankevicius Apr 17 at 20:44
@r.pankevicius Honestly, I just stopped giving estimates: rclayton.silvrback.com/software-estimation-is-a-losing-game –  Sergio Acosta Apr 18 at 5:16

13 Answers 13

up vote 156 down vote accepted

From The Pragmatic Programmer: From Journeyman to Master:

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

In the section, the authors recommend the following process:

  • Determine the accuracy that you need. Based on the duration, you can quote the estimate in different precision. Saying "5 to 6 months" is different than saying "150 days". If you slip a little into the 7th month, you're still pretty accurate. But if you slip into the 180th or 210th day, not so much.
  • Make sure you understand what is being asked. Determine the scope of the problem.
  • Model the system. A model might be a mental model, diagrams, or existing data records. Decompose this model and build estimates from the components. Assign values and error ranges (+/-) to each value.
  • Calculate the estimate based on your model.
  • Track your estimates. Record information about the problem you are estimating, your estimate, and the actual values.
  • Other things to include in your estimate are developing and documenting requirements or changes to requirements specifications, creating or updating design documents and specifications, testing (unit, integration, and acceptance), creating or updating user's manuals or READMEs with the changes. If 2 or more people working together, there's overhead of communication (phone calls, emails, meetings) and merging source code. If it's a long task, account for things like other work, time off (holidays, vacation, sick time), meetings, and other overhead tasks when picking a delivery date.
share|improve this answer
This is also a big part of McConnells's "Black Art of Software Estimation". Never off-the-cuff it. –  Paul Nathan Sep 3 '10 at 17:35
+1 but, in some circumstances, you really can't say "i'll get back to you". –  systempuntoout Sep 3 '10 at 18:32
I highly recommend the McConnell book. If possible, ask anyone who needs an estimate from you to take his estimating quiz: codinghorror.com/blog/2006/06/… You can present it as a game, but it often helps to get the message across. –  Paddyslacker Sep 3 '10 at 20:57
You can always say "I'll get back to you." If someone says "Well, I need an answer," say "If I give you an answer now, it will be a lie. I do not have enough information right now. It would be a disservice to us both for me to make something up on the spot." –  Andy Lester Oct 8 '10 at 22:14
@AndyLester - plenty of situations arise where if YOU don't give an answer now, someone else will, and either take the project and the money with them, or still pin the blame on you in the end for missing an estimate you had nothing to do with. It sucks, and it's wrong, but it's unfortunately reality. –  Joris Timmermans Nov 17 '11 at 14:24

Software estimation is the most difficult single task in software engineering- a close second being requirements elicitation.

There are a lot of tactics for creating them, all based on getting good requirements first. But when your back's against the wall and they refuse to give you better details, Fake It:

  1. Take a good look at the requirements you have.
  2. Make assumptions to fill in the gaps based on your best guess of what they want
  3. Write down all your assumptions
  4. Make them sit down, read, and agree to your assumptions (or, if you're lucky, get them to give in and give you real requirements).
  5. Now you have detailed requirements that you can estimate from.

It's like my mother used to threaten when I was a kid "Hurry up and pick out some clothes, or I'll pick them out for you!"

share|improve this answer
+1 for clothes picking threat. Showing your assumptions when giving a guesstimate is something I will try more often. –  DarenW Oct 12 '10 at 19:23
I asked a follow up question concerning your 3rd point. programmers.stackexchange.com/questions/132970/… –  k0pernikus Feb 2 '12 at 13:24
Guess we need to up it to 3 hard things. –  jpmc26 Jan 21 at 10:42

I did development for a guy who was very adamant about wanting accurate estimates. What we settled on, which worked very well, was this:

  • I billed for all the time I spent estimating. It came to around 20-25% of what I billed.
  • I did extremely detailed examination of the tasks. No shooting from the hip. I went into the code, figured out what lines needed to be changed, what other parts of the program it would affect, how much testing I'd have to do to ensure that things still worked. I'd estimate each piece in units of .1 hours (6 minutes).
  • I sent him my estimate for each task along with that detailed breakdown.

20-25% of billing sounds like a lot.

But he'd ask me to make change XYZ, thinking it'd take about 2 hours. In 1 hour of detailed estimating, I'd determine it'd take 8.5 hours. So he'd decide whether it was worth 8.5 hours of pay. If not, then he saved 7.5 hours over what it would've cost him if I'd done it without an estimate.

And if he did want to invest the 8.5 hours, the detail work I did for the estimate was work I'd have had to do anyway.

I found that with this method I was able to bring most tasks in on time or even early, without having to heavily overestimate. Because the time was broken down so minutely, I could tell early on if I was slipping. If I hit roadblocks so that after 3 hours I could tell that my 8.5-hour task was going to take 12, I could talk to him about it before more time passed so he could reevaluate and yank the feature if he was concerned about the cost.

Was he nickel-and-diming? No, I looked at it as letting him apply his money where he saw the most benefit. And I was glad to get experience in estimating, which I'd always been terrible at.

share|improve this answer
That sounds like a very adequate technique. In fact, when you are making an estimate for your own company the estimate time is being paid as part of your salary also. I'm afraid, however, that the problem is that most organizations want estimates of much bigger tasks than the ones that can be expressed in .1 hour chunks. Thanks for your answer. (Are you the same Kyralessa from the joel on software boards?) –  Sergio Acosta Sep 29 '10 at 6:05
Yes, the same one. –  Kyralessa Sep 29 '10 at 13:32
@SergioAcosta the point is you use the analysis/estimation time to break down the task into smaller chunks. This is the best answer, imho. –  NimChimpsky Aug 7 at 7:40

It depends on what the estimate is for.

For an initial, high-level estimate for a business case then the key things are:

  1. Speed. Whatever method you use it needs to be quick. The whole point is the stakeholders aren't sure if it is even worth doing the project - which is why they need the numbers for the business case. If the business case was solid they wouldn't need your estimates. The bulk of these projects won't go ahead so it is important that too much effort isn't expended providing the estimate.
  2. Give a range. Make it broad. You have had no time to analyse requirements, workshop with stakeholders, validate assumptions. A wide range tells the recipient of the estimate "Software projects are naturally complex and risky - if you want a proper estimate you need to give me more details and more time". The problem with giving a single number or a narrow range is that it paints you into a corner by setting expectations before any real analysis is done.

I find the best technique to pick a comparable project that "feels" the same. "Feel" is completely subjective - but with this kind of estimate my experience tells me you won't find objective measurements. Then provide a wide range. I've read some books that say a range of -50% to +100% is good but it depends on many factors.

For a detailed, low-level estimate:

  1. You need a baseline. If the baseline isn't stable the estimate is meaningless.
  2. Bottom up is best. Get a detailed work breakdown, estimate each component then roll it up into a larger number. I find planning poker to be a great technique here.
  3. Document contingency. Make it clear where any contingency (if any) is added. Is it added to each line item? Or to the whole estimate? Or to specific risks? Or is there none?
  4. State your assumptions. Validate as many as possible given the time frame.
  5. State explicitly what is included and excluded in the estimate. For example, is review included? Are technical delays included?
share|improve this answer
Awesome answer and very pragmatic –  hydrogen Mar 16 '11 at 9:08
+1 for giving a wide range. I always forget about that; never say "1 month" when you can say "1 to 2 months." –  jhocking Sep 13 '11 at 12:20

We're often asked for an "ballpark estimate" during meetings where we're given very broad and vauge ideas of what they'd like to do. I always say, "if you want an answer today it's a year and a million dollars. If you'd like to give me a lot more details and some time to review them then I can refine those numbers for you."

They almost always get the point.

share|improve this answer
"ballbark estimate" - is that like a ballpark estimate? –  Hugo Sep 13 '11 at 5:29
Yes, but without the typo... :) –  Walter Sep 13 '11 at 12:11
I've been in those kinds of meetings. I think ballbark is the better word. –  Mike Sherrill 'Cat Recall' Sep 23 '13 at 0:19

There is a blog entry that outlines how to keep a record of how accurate your previous estimations have gone, and then next time you say to someone "it'll be two weeks", you can look at your previous history and see how long it actually took last time you said "it'll be two weeks".

I haven't tried it myself, but I'd like to, to see how accurate my estimations are.

share|improve this answer
Joel's Fogbugz goes further on that and analyses your data for you using evidence based scheduling. Ie, each developer enters how long they think each task will take, and later, how long that task took, and it guages how accurate each developer is with their estimates to produce a probability curve for a finish date. –  Chris Buckett Sep 26 '10 at 19:49

"Two weeks!"

Seriously. My first estimate is always two weeks. Because I have some sort of bizarre mental block that makes me think everything sounds like it'll two weeks.

I try to work around it, try to really think about how long I think something will take, trying to identify all the potential trouble spots and bits that look too black-box-y for me to be accurately estimating. And try to recognize that if my answer is "Two weeks!", I've likely failed to do so.

Pretty much every good manager I've had has learned to recognize "Two weeks!" as an answer that requires a mild verbal pimp-slap in response.

share|improve this answer

It depends on the organization and how the estimates are used.

If the estimate is just to provide a general idea on when it will be ready, I can generally do a quick estimate based on my experience. Often times I will include any uncertainty or possible variations with the estimate along with how the changes may impact other areas of the system and the extent of regression testing required.

If the estimate is used for anything contractual or in a scenario where more precise timing is required, I do a full work break down. This is more work and requires more in depth thinking about the design and changes to the system, but is much more accurate, especially for larger pieces of work.

In either case, on-going communication is key. If you do run into something unexpected, make it known at the time instead of waiting until the deadline. If the requirements are not-clear, make sure you document your understanding of them and the functionality that you plan to deliver. This is also helpful with any assumptions you make. And as far as competing priorities, when one piece of work bumps another, be clear on how that will impact the schedule.

share|improve this answer

Estimates for what? Small tasks or complete solutions.

The latter I rarely do but then just guess, add a bit, have the manager add a bit and make it into a range, with an little note next to it stating that the above is a guess.

Small tasks - Planning poker I've found to work really well (not perfect, some 1pt tasks have taken much longer and some 5pt tasks took minutes, but it all evens out in the end).

share|improve this answer
Yay planning poker! –  Sean McMillan Aug 9 '11 at 17:56

Present a range based on what you know today. Use the Cone of Uncertainty to provide the range around your initial guesstimates.

Every week calculate how much is left to do, re-estimate based on what you know. Once you have enough of a sample size of how much work you are getting through each week, provide a 90% confidence interval for what's left to give a (usually) ever narrowing date range as the project progresses and the amount of work left (hopefully) shrinks.

share|improve this answer

Sometimes estimating becomes an enormous challenge for you and your team, especially when we are talking about software project estimation.

Once we had decided to share our experience and our knowledge about software estimation process and defined four distinct types of estimations:

  • ballpark figure
  • service estimate
  • feature estimate
  • componential estimate

Of course, those types are distinct. Ballpark is what is often called a “guesstimate”. So it's an approximate number or range that gives a general idea of cost and that may help a prospect decide whether they would like to take the discussion further.

As a rule, clients need a ballpark figure at the beginning of the project. And our advise is: discussion of the project and providing ballpark figures should just be steps well towards receiving componential estimate (which is flexible, one can make use of componential type estimate for the whole development process. No need to re-estimate from scratch when you want to add, remove or replace features, services etc).

Everyone should keep in mind the risks that come with software development estimating: underestimating, overestimating, total epic fail scenario etc.

You can read more on our blog!


Hope this information will help you!

share|improve this answer

Confidently. I can't tell you how many times I botched up an initial meeting with a client by not putting on professionalism when giving an estimate. Even if you're blowing numbers out of thin air - make sure you always keep some estimate around. That said, be careful not to estimate yourself into a hole. Different things take different amount amounts of time, effort and resources to put together. Here's a good way to do it:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

share|improve this answer

First, if some task was assigned to me I would break it down into subtasks.I would estimate the time for each subtasks and probably with subtasks I would be able to find the problematic area and hence I would be able to forecast how long it would take to a certain extent.

But still all the planning would help only to a certain extent. Only when you start coding you can find the exact issues

share|improve this answer

protected by gnat May 16 '14 at 18:06


Would you like to answer one of these unanswered questions instead?
