I am looking for some insight from you smart people on SO. I'm a relatively new developer (3+ years of experience) primarily on the .NET framework, and I'm absolutely terrible at knowing how to properly estimate even the smallest of projects. I know that it's going to be a pretty big hindrance to my upward mobility as well as my joy of programming if I don't figure out good tools, methodologies, approaches, etc. Therefore, I am seeking your knowledge and wisdom on this subject.

I have heard of SWAG and have most of the time employed that to give my estimates in the past, but I don't feel comfortable just "feeling it out." Certainly, from my experience of doing similar projects I can recall how long it took me and give a relatively accurate estimate, but even that isn't always very accurate. Plus, it seems that inherent in every project are gotchas and unforeseeables to make estimating even more difficult. Thoughts?

  • The book Agile Estimating and Planning has been very helpful for me. I highly recommend it. Commented Apr 15, 2011 at 4:40
  • 4
    take your best guess at how long you think it will take. Then round up to the next logical unit of time, e.g. minutes becomes hours, hours become days, days become weeks, et al. Then double it. No wait, that's how Montgomery Scott estimates... Commented Apr 15, 2011 at 4:44
  • @Steven: And Scotty was a miracle worker. Commented Apr 15, 2011 at 4:58
  • Thanks all for the very helpful answers, comments, and suggestions. In the end though, I still get a feeling that it's still very difficult (maybe if not impossible) to be able to measure the work at a very atomic level to give a truly accurate estimate. Does that supposition sound reasonable?
    – ChuckT
    Commented Apr 15, 2011 at 13:56
  • Totally reasonable. Commented Apr 15, 2011 at 15:09

7 Answers 7


I really liked the idea of Evidence Based Scheduling, and had some success with it. By using statistical measures of your past estimation accuracy, it gives you a confidence interval of how accurate your future estimates are likely to be, rather than a fixed date. The drawbacks I found were that it requires remembering to update a tool with your time spent at the end of a task, something I have never been very good at being diligent with, as it is very difficult to do accurately if you frequently switch between tasks. Also, even though it is supposed to take the probability of interruptions and side tracks into account, I still felt like my estimates were a shot in the dark.

Recently, I've started using the pomodoro technique, and it has really improved my feel both for how much uninterrupted, focused time it tasks to finish certain kinds of tasks, and how much uninterrupted, focused time I have available in a typical day. The previous mental blocks with remembering to record my time spent aren't an issue because it is basically only one button push at the end of every 25-minute interval to record it. I'm currently working on a tool for myself that hybridizes EBS and pomodoro to take the best of both worlds.

  • WOW, I do like Joel's layout of EBS. Thanks for posting that!
    – ChuckT
    Commented Apr 15, 2011 at 14:37
  • would you like to share the tool? Commented May 14, 2011 at 17:48
  • @Aivan, I'll probably put it up on github or something when I get it to a decent state. That's going to be a while as I'm currently in a pre-release crunch time at work where I don't have much time for working on tools. Commented May 14, 2011 at 17:56
  • great. do you have twitter an email or something. this is really interesting Commented May 16, 2011 at 13:12
  • I like this and find that Pivotal Tracker is great tool to give you that 'velocity' (their term) based on work that's actually been completed. Other tools give you this too, personally I've comd to prefer Pivotal Tracker over Trac, Trello, etc. It's a bit of a chicken-and-egg scenario for the first project, or phase, but once you have a couple done or a few weeks done, if you categorize things using the same level of effort metrics, you can base estimate on actual past experience rather than on wholly future guesses. Commented Mar 15, 2012 at 21:38

Despite our often sarcastic and wry nature, programmers are extreme optimists when it comes to estimating how long tasks will take.

I don't follow a formal methodolgy but do have a system that seems to work reasonably well.

My usual approach is to think through all of the tasks and figure out how long it would take me (as an experienced developer) to do them. That becomes my baseline. If the project will be done by an average group of developers, I double my estimate. if it will be done by new developers I triple it. If it is to be done by interns, I quadruple it and warn everyone affiliated that the final product the interns produce will almost certainly have to be thrown away and rewritten. Interns writing complex systems is a horribly bad idea.

This is the effort estimate. From there, you need to add in time for testing, deployment, troubleshooting and, of course, meetings with the customer. On an average project for me, this comes to about 10-20% of the effort estimate.

Any project will have a certain amount of unknowns, so that may start out at 5% for established technologies with a defined end product and go as high as 100% for cutting edge technology with a moving target as an end-goal. If you know where the big unknowns are (i.e. a new framework for doing XYZ) then allow extra time for all tasks that interact with that unknown.

After you estimate do a few projects, you'll get a feel for where your personal blind spots are and will learn to pad those areas a bit more.

Naturally, once you give this estimate to your supervisor they will probably double it when they relay it to the interested parties, simply because they know how Programmers tend to be optimistic :)

  • I almost began to ask the question you basically answered by reading your last paragraph. A former coworker told me that during his stint in the military, his boss would always tell him to take the number he came up with and double it. I wonder if that is a pretty common practice.
    – ChuckT
    Commented Apr 15, 2011 at 3:42
  • 2
    @ChuckT - It is a common practice, unfortunately. A task that would really take a month, winds up being killed by upper management for costing too much. Indeed, with all the buffering, by the time it gets to them it's just too expensive. A more reasonable approach is to ask for a prioritized list of things, then break each one down until I can be confident that each individual task can be done in under a couple of days (in my experience when a programmer says that something is going to take more than 2 days, they're really saying "it's big but I don't know how big").
    – Julio
    Commented Apr 15, 2011 at 14:53
  • @Julio So, do you see the problem in that situation being the estimations given or the fact that the business heads are unwilling to commit to anything, or is it something else?
    – ChuckT
    Commented Apr 15, 2011 at 14:58
  • @ChuckT - I suppose we (as an industry) do this for historical reasons. Traditionally developers get estimates wrong so we double it. The problem is all layers up the chain double it. In a big org, by the time it gets to the CEO, it costs a year to replace the company logo on the front page. To be fair, they double everything because we suck at estimating. In part because we're too lazy to really try to understand what needs to be done, and in part because we're arrogant enough to think we can do anything by tomorrow morning.
    – Julio
    Commented Apr 15, 2011 at 15:02
  • I add 5 units of whatever unit, then multiply by 4. For example: 3 hours projected + 5 hours = 8 hours, times 4 = 32 hours. Sounds right. But that means everything has been done and the end user is happy. 3 days becomes 32 days. Commented Apr 15, 2011 at 16:16

I don't know why, but it always seems to work out fairly well for me to take the average estimate of the programmers involved and multiply by 3. It feels like throwing darts at a board, but it often comes out closer than more formal estimating methods.

  • Do you use that strategy regardless of the size and complexity of the project?
    – ChuckT
    Commented Apr 15, 2011 at 14:00
  • 1
    I don't estimate big projects, that is foolish and you will never ever ever get it right. Break it down into smaller projects and estimate those. That's the technique I normally use, but the 3x rule is how I figure out the subcomponents.
    – JohnFx
    Commented Apr 15, 2011 at 20:36
  • This works well for me too Commented Mar 9, 2018 at 13:58

Accuracy of project estimation is heavily dependant on the clients ability and will to translate their desires into business requirements without introducing heavy scope creep. And, the clients patience for proper planning.

Given good business requirements and minimal scoop creep we still face the problem of estimating complexity...no easy task.

Now, I work for big business. Often, where software is a cost center. In this environment, one must deal with a certain level of quality. Substandard to that of say...Google.

In an attempt to offset this low quality I have come up with my own method of attack. Basically take:

  • Business requirements (which could be anywhere from 1 - 100%) complete.
  • Break the requirements into tasks.
  • Now, you can either shift the tasks into a timeline, see gantt chart, or go to step 4.
  • Translate the tasks into high level technical requirements. This could be formal written plans. But, I usually do not do this on paper. Instead, create a set of classes/interfaces with no implementation. Something like red/green refactor.
  • Now, one can more accurately estimate complexity to implement classes than say, "how long will it take to make an inventory tracking website?".

Obviously, there's a lot of team dependancy in the process. So my advice is to try and be light-hearted and just do your best. There's only so much we can do.

  • Thanks for laying those points out. Makes for a good mental roadmap. It's funny that I do remember how difficult it was to grasp a concept in school until we started implementing it in code with classes and interfaces. That also makes for a bit of a chicken and egg situation. For me, it seems I have to do some implementation, even if it's just the bones of the work, in order to estimate what it will take to put the meat on the bones.
    – ChuckT
    Commented Apr 15, 2011 at 16:52
  • You have just described waterfall
    – JohnFx
    Commented Mar 10, 2018 at 18:16

For estimating purpose over the years I have developped a "recipe" for estimating task.

First instead of calculating by hours I use day fractions where 0.25 is 2 hours (based on a 8h per day).

I try to breakdown each task to get a maximum of 1 unit (or 1 day). After that you can have a good estimate for producing a good Beta version.

Then I had a 45% of that time on refactoring/documenting/optimizing and finally a full 100% for debugging and test (in house and with the client)

When I sum everything I get, for a 1 day estimate, a result of 20 hours of real work.

Finally I divide that 20 / {real working hours} to get the number of days required to develop the final version.

Initially the testing/debugging part will not be used up right away but on the long term it will eventually be.

Combine that with EBS and you can get a probable delivery date that works


We use the technique of componential estimate. It's how we call the type of estimation which is the most risk free for both – suppliers and clients

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. You can easily remove a feature without affecting the accuracy - as you can see, this type is very flexible. It’s as closest as one might get to the precise price estimate. With a clear componential estimate, a prospect will have full understanding of what they pay for.

But to make such an estimate you should have clear requirements, understand all features of the project and what services your client needs. Usually you don't, but you should try. As a result you'll get a successful project and a happy client.

Hope this information will help you! For our team it's the best technique to make an accurate estimate.


Have a read of Software Estimation: Demystifying the Black Art by Steve McConnell - there are many different techniques described.

My advice is to give a 3 point estimate as it helps to communicate the risk of the work being undertaken and forces you to think about what could possibly go wrong.

Also run your estimates past someone else first before you commit to them. And if there are multiple people working on the task I found Planning Poker a great technique.

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