How do you accurately create estimates for programming projects given to you?

Question

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?

Answer 1

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.

Answer 2

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 :)

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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