It seems that, in my experience, getting us engineers to accurately estimate and determine tasks to be completed is like pulling teeth. Rather than just giving a swag estimate of 2-3 weeks or 3-6 months... what is the simplest way to define software schedules so they are not so painful to define? For instance, customer A wants a feature by 02/01/2011. How do you schedule time to implement this feature knowing that other bug fixes may be needed along the way and take up additional engineering time?

  • 33
    I have discovered a truly marvelous proof that it is impossible to estimate all complex development tasks accurately, or perfectly schedule these tasks, or in general, any schedule that is based on estimates. This comment box is too small to contain it. Commented Jan 8, 2011 at 3:14
  • 2
    @Dan McGrath: Why don't you post a link containing the proof? Wait, are you trying to be like Fermat and his last theorem proof, which was never found :| Commented Jan 8, 2011 at 6:20
  • 9
    For the same reason that it is difficult to plan a trip when the navigator is not sure of the destination, the driver doesn't know the roads, and the passengers all want ice cream. Commented Jan 8, 2011 at 9:00
  • 1
    Something that might interest you is Evidence Based Scheduling.
    – Craige
    Commented Jan 8, 2011 at 9:07
  • 2
    They are not hard to define. Just impossible to keep to. Commented Mar 7, 2013 at 22:27

13 Answers 13


If you are cranking out a project nearly identical to other projects you have done, using familiar tools and a familiar team, and you are given firm, written requirements, then it should be possible to make good estimate.

These are the conditions that painters, carpet installers, landscapers, etc., regularly experience. But it is not a good fit for many (or most) software projects.

We're often asked to estimate projects that use new tools, technologies, where requirements are changing,etc. This is more extrapolation into the unknown than interpolation over our past experiences. So it is natural that estimation will be more difficult.

  • 20
    Excellent points. It's like asking how long will it take you to drive somewhere you've never been. You can give an estimate based on distance, but you can't factor the amount of traffic during rush hour.
    – JeffO
    Commented Jan 8, 2011 at 3:29
  • 2
    @Jeff That's a very good comparison. I'll have to remember that one Commented Jan 8, 2011 at 4:15
  • 1
    @Jeff ...but you can known it is rush hour and add that fact to your estimates...you might still be off, but not by as much
    – Pemdas
    Commented Jan 8, 2011 at 4:45
  • 2
    @Pemdas: Actually, you can't know enough to add all the facts to your estimates. You can't know if the fire department is responding to a call. You can't know if an electrical wire has fallen and is blocking the road. There are an infinite number of things you can't know about the future. It's the future. It's hard to predict -- by definition.
    – S.Lott
    Commented Jan 8, 2011 at 12:08
  • 1
    @Pemdas - the more complex the task, the more the gods of chaos interfere. Of course that probably fits your point more than some of the comments - with familiar tasks, you know how interested those pesky gods tend to get.
    – user8709
    Commented Jan 9, 2011 at 7:25

According to my personal experience, it's exactly the opposite of what Pemdas said: with practice, I've just understood that it's totally impossible to estimate how much time a task will require. At the beginning of my career in software development, I often gave estimates like "45 days", "five weeks", etc., then tried very hard to finish in time. A few years after, I started to give less precise estimates like "approx. one month", "five to seven weeks", etc. Actually, I try either to not to give any estimate, or ask the customer to give her own estimate or deadline or I give an estimate as rough as possible.

Why is it so difficult to have an estimate? Because it's nearly impossible to know how the whole source code will be written before actually write it, and because your work depends on random things as other peoples work, your motivation, etc. Here's a more detailed list of the possible reasons:

  1. It's not easy to know what exactly is required to do a product, and especially how to do it. Very often I started some parts of an application, than, after days of work, understood that my first approach was wrong, and that there is a better and smarter way to do things.

  2. Some problems may arise. For example, if, to begin your work, you must install on your machine a fancy SQL server and the installation fails and the support is nonexistent, you may spend weeks solving this issue.

  3. Requirements are often not clear enough, but after reading them at the beginning, you think they are. Sometimes you can understand that the mean 'A', and, after starting to implement them, you would notice that they maybe mean 'B'.

  4. Customers like change their requirements exactly when you've just finished the concerned part, and they really don't understand why are you requesting two more weeks and $2000 to do a tiny change, because they don't see that this tiny change requires to change other things, which require to change others, etc.

  5. You can't estimate your motivation. There are days when you can work for hours and succeed well. There are weeks when, after writing ten lines of code, you switch to Programmers StackExchange, and spend hours reading ans answering questions.

  6. Things become really bad when your estimate depends on other people. For example, in one 2 month project I had to wait for a designer to do his work to finish my own. This designer took 3 months before delivering a piece of unusable crap. Of course the project was late.

  7. Your estimate also depends on your customer. I had customers who spend weeks before answering their mail. It can really affect your schedule when you must wait for their answer (for example if you are asking them to precise a requirement).

What can you do?

  1. Give a larger schedule. If you think you can do the job in two weeks, say you will deliver it in one month.

  2. Be clear. If you rely on a designer, another developer, etc., say it. Instead of telling "I will deliver the product in three months", say "I will deliver the product in two months after the designer will give me PSD files."

  3. Explain that if requirements change every day, the project will hardly be delivered in time.

  4. Slice your schedule. Delivering parts of a large project on time is easier.

  5. Never give an estimate when you use a product you don't know well or, especially, when you will work on a source code of somebody else: you can never predict how crappy the source code can be and how much time you'll spend understanding and copy-pasting it to The Daily WTF.

  • 1
    @Jeff O: I don't know. For me, a delivery date means a deadline. And a deadline means that the project cannot be delivered after it. Also, psychologically, customers might be less angry when you said you will deliver something in a month and you deliver it four days later, than if, at Jan 8th, 2011, you say you will deliver it at Feb 8th, 2011, and you deliver it Feb 12th. Commented Jan 8, 2011 at 4:00
  • 11
    @Pemdas: it's not a question of laziness. You can just be depressed, or having temporary difficulties to concentrate, or having personal/family problems, or be too stressed by other customers or whatever. Commented Jan 8, 2011 at 4:34
  • 2
    Adding to points of MainMa, if you work in a team, there are situations when someone needs to be on leave, for joy or sickness. Commented Jan 8, 2011 at 6:31
  • 6
    @Pemdas They happen to some extent with every programmer. It's just that it manifests itself in ways that aren't always obvious. One week working through a given problem might take 3 hours because you're super-sharp and "in the zone," while the next week it takes 3 days. Commented Jan 8, 2011 at 11:54
  • 7
    @0A0D If you break the project down into its most granular subtasks and figure out exactly how each of them will function, then work through everything to ensure that you understand the implications of those pieces combining, and thoroughly review any new or not-fresh-in-your-mind technologies involved, and get every unknown out of the way, then you absolutely can provide a pretty darned accurate estimate. Of course, you've also done nearly all of the programming, leaving just the coding part, and you can't know in advance how long all of that estimating will take. ;) Commented Jan 10, 2011 at 4:39

A very similar question is "How long will it take to solve this crossword puzzle?"

You cannot answer that until you have had a look at it to see numerous things like:

  • Is it in a familiar language? (Spanish versus English versus Chinese)
  • Is it one of a type we have solved before? (One in a series running in a magazine e.g.)
  • Do any of the leads require additional knowledge before we can even understand it?
  • Is there anywhere in the puzzle things that, to your knowledge, will require additional work?

Since there are usually several new things in a project (otherwise it would not be a project) you cannot tell how long time they will take to solve until you have had a very careful look at them. Perhaps even solve more or less or them, and then you are still not certain that there isn't a surprise or two where you didn't think of them.

Also there is a strong pressure to do it as cheaply as possible, hence as quickly as possible and the blame for a too low estimate does not go on the project manager pressurizing but the developer giving the estimate. It does not take many iterations for the developer to catch this, and learning to be VERY weary of giving out any absolute numbers.


The most obvious reason why you engineers can't give you accurate estimates is that it's impossible.

Of course you can estimate how much time +-2 minutes it will take from your home to work. You know how to drive a car, you can evaluate the traffic, and some other external factors.

Tell me how much time it will take you to drive from London to Barcelona. Without any advanced GPS planning tools of course. Using the good old method like we still do in software estimation. Empirical estimation and predictions.

In software, it's worse:

  1. Estimates often become a commitment, so our judgment is modified.
  2. There can be huge differences between the estimation of Bob and Karl for the same task.
  3. Uncertainties are very common, how much of us get stuck on a stupid bug or hard drive crash destroying any apparent good estimation.
  4. We usually forget about all other tasks than programming including meetings, phone calls, helping our coleague, etc.
  5. Human brain is limited. It has not been designed to estimate long running tasks.

That's why it's impossible to tell your customer what you will be able to ship for the 02/01/2011 with good accuracy, and forget about the 03/01/2011.

To address all those problems, I recommend you advanced estimation techniques such as Planning Poker (disclaimer: this is one of my website) and Iterative Development with Velocity calculation.

  • The first two issues are addressed using Planning Poker. Estimations are collective and the team owns them rather than individuals.
  • The last third issues are addressed using Velocity and Iterative Development. By knowing your velocity (the factor to apply to your estimations based on history), you can plan releases with more confidence. Iterative development, when well done, bring most important features to the top and helps you deliver value to your users early.
  • So if someone asks for a delivery date of 02/01/2011 for a feature, the best bet is to say "as soon as I am working on it, I will let you know how long it will take"? I'm sure that would go over well like a lead balloon ;) Commented Jan 8, 2011 at 14:48
  • 0A0D: it depends on the situation. With a team that doesn't known each other, I wouldn't bet on ANY deadline. However if you know your average velocity, use collective estimations and practice iterative development, you can set a deadline with much more confidence.
    – user2567
    Commented Jan 8, 2011 at 15:00
  • @0A0D, in Europe 02/01/2011 means January 2nd. At least it makes the answer easier when asked on January 8th :D
    – user1249
    Commented Feb 5, 2011 at 17:02

Software development is -- by definition -- an act of discovery and invention. It must always involve something unknown.

The only time everything related to software development is known is when the software is complete.

The only time there's no unknown technology or business feature is when it's a complete, packaged solution ready for download.

The reason we write new software is because we have a new feature or new technology or both. New means new -- unknown -- unpredictable.

Because software development must involve novelty, the development effort cannot be predicted.


Honestly, I think it just takes practice. If you write enough code eventually you should be "fairly" accurate. My first boss believed that this skill was important enough that he requested that I informally practice this on every feature/project that I implemented. After each project we reviewed the estimates and attempted to figure out where I went wrong. Eventually, you get the hang of it.

  • Agreed on the review, but I'm really curious: @Pemdas, do you tend to work on the same kinds of problems for each project, with only minor changes? Are you referring to reasonably simple stuff, maybe one more RESTful service that basically just returns database table rows or something? Having worked with many dozens of programmers and having hired dozens as well, I've yet to find someone who could give accurate estimates for problems full of unknowns. Commented Jan 8, 2011 at 11:59
  • I work on the same product, but the problem sets change with ever release. I will admit that I have never had to estimate something that took more than 6-8 months to complete.
    – Pemdas
    Commented Jan 8, 2011 at 16:38
  • Perndas, just for the fun of it: How long will it take to rewrite your product in C# or Java? To run in the Google cloud? To visualize data live in OpenGL? To have an end-user client running on a Wii?
    – user1249
    Commented Jan 8, 2011 at 23:09
  • Maybe our definition of estimations is wrong. There is definitely a period of research required before you can give a reasonable estimate, which I do not usually include my time to delivery estimations. I can not reasonable answer any of those questions with out first doing some research. I would never assume to be able to give an estimate without understanding the technologies.
    – Pemdas
    Commented Jan 8, 2011 at 23:43

It's never easy. You just try to get better at it.

One advantage of breaking up your deliverable code into smaller pieces, is so clients get an understanding of what to expect and when to expect it. Now you have some sort of baseline for them to use as a reference.

If they have a strict definition of a feature that they need at a defined time, they need to know that additional resources have to be allocated to this request. They are taking a risk in the severity of the bugs that occur and how long they can go without them being fixed. When something major comes up, you go back to the client and force them into a decision. Do I fix the bug or make the deadline on the new feature? Give them enough information to make an informed decision.

Hopefully you have enough history of working together and have established yourself enough to be trusted. You can't expect them to fully understand the development process, but you can make them feel you are putting forth an honest effort and not taking advantage of their lack of knowledge.

  • I didn't even think about incremental releases. That is a great tool to give the customer some sense progress. Although, I don't work with "external" clients, with do practice this in house, it is great way to pipeline testing with development.
    – Pemdas
    Commented Jan 8, 2011 at 5:04

Because we do the schedule too early. See Construx's article on doing a preliminary rough one, then better one later. Also if you don't track how you did on prior estimates, it is hard to get better. FogBugz does that [a customer of their free one, no other conflict of interest].


I have learned a lot from this book:

Software Estimation: Demystifying the Black Art

In short to get better estimation results we do this:

  1. all but trivial tasks are estimated by more then one person (two in our case)
  2. we divide task into smaller task. The more tasks you have the more likely your estimation will be good - law of large numbers if I remember correctly from the boo
  3. we estimate worst, best and most likely scenario. Sometimes each of us estimates those tree scenarios totally differently. That means we have to talk and usually it turns out that one of us did not understand the task. Had that one person estimated the task alone it would be estimated wrong.
  4. we put 3 numbers from above point into equation and receive estimation (excell) k

After work task is finished and our estimate was wrong we try to find reasons why. And we incorporate this knowledge into next estimation process. So far this is the best process I have used for estimation of bigger tasks. When I say task I mean jobs that take from about 50-500 hours.


Note: This really only applies to projects where you bill by the hour versus a fixed/flat rate.

I usually try to plan out my schedule so that it consists of essentially a bunch of SCRUM Sprints (whether using SCRUM or not). Up front when making the schedule I determine what the length each sprint will be and what the features will be for the project. Typically there are some features that have to be done first so I try to give a best estimate (not to be confused with optimistic) for those and any features that will be towards the end of the project will have generalized estimates. After mapping the features to sprints I try to add 1 to 2 sprints at the tail end of the project to account for features that slide right and for features that were overlooked in the original requirements gathering.

The key to this is that I make all of this transparent to the client upfront so they understand why the last two sprints are empty or sparsely populated. At least to this point the client's I've worked with have liked this since they know that there is some cushion in the schedule/financials since most of them are aware that SW estimates tend to be less than concrete. They are also aware that if we don't need the last sprint or so then those are hours that we don't bill. With the transparency in how the schedule is built and the regular feedback on how progress is going during the execution of the project every client that I've done this with has been extremely satisfied.


In addition to all the things named, I see these two things as some of the biggest problems. First you estimate the final date based on every devloper being available for the full 8 hours a day 5 days a week. This is incorrect and will virtually 100% guarantee that the end date is missed on any project that is not trivial. People take time off, attend company (or non-project-based) meetings , fight with HR over health insurance claims, take breaks, etc. Never assume more than a 6-hour availability per developer per day.

Next devlopers notoriously forget to estimate all the non-development tasks like meetings and emails concerning the project, deployment, QA support, UAT support, writing unit tests, research, documentation etc. Once we added these types of task to our estimation spreadsheet, our estimates got way better.

  • I wouldn't call writing unit tests non-development task ;) And our bosses count us for 6 hours a day. If I say 60 hours they say 10 days. Commented Mar 7, 2013 at 22:39
  • @Peri, Granted I wouldn't either really, but many people do forget to add time for writing tests and only think of the main problem at hand. Good for your bosses, it amazes me how many don't.
    – HLGEM
    Commented Mar 8, 2013 at 14:43

When it comes to time estimation for tasks which can take longer then a few hours I try my best to use this rules:

  1. Don't ever try to predict when other people will finish their job if you happen to depend on it. Speak only for yourself.
  2. First analyse the task, then estimate. By analysing I mean at least writing down (and not trying to keep everything in you head!) a list of subtasks with estimation for each one of them.
  3. If a task is complex enough, estimate the time for such analysis itself. Let the estimation be a separate process. You may also make sure your boss knows about that.
  4. Don't estimate under pressure. Make it clear that it takes time to make a reasonable estimation and just tell them something like "I will name a date tomorrow by 11:00 when I'll finish analysing the task". I know some customers/managers can press hard, but they shall not pass. Put your busy face on and claim your time!
  5. Ask a little more time than you think you'll need because you probably forgot to add a coffee break time (and othe distrctions) in your estimation.
  6. For big tasks ask even more - there will probably be more than one coffee break.
  7. If you really can't estimate (the task is too difficult/unfamiliar) or really unsure - ask someone capable for help with your analysis.

There's probably more rules than that, but I actually don't have a poster with this rules on my wall. I just formulated them now, but they come from my experience (so it may not work for you).

The only reliable way to schedule software development I can think of (but I haven't actually tried it) is Evidence Based Scheduling which is basically the Monte Carlo method used to count probability of a ship date based on historical records about tasks that you've accomplished before. It feels nice because it doesn't try to use any metrics other than estimated and actual time. However, it requires a lot of experience to split big tasks into smaller ones beforehand and you have to have a big set of historical data to make it work precise enough.


There are "known unknowns" and "unknown unknowns." :-)

  1. Estimates often become deadlines.

    • Nobody want to miss a deadline and become headline!
  2. Requirements change (often rationally) and the programmer cannot veto it.

  3. Programmer do/may not have control on factors such as

    • Availability of code she is depedent on
    • Quality of code she is dependent on
    • Overall architecture and design of the system
    • APIs to access other parts of the system

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.