Determing software estimates and tracking past estimates

Question

Possible Duplicates:
How to estimate the length of a programming task
What can I do to get better at estimating how long projects are going to take?

I know that this probably has as many answers as users here on SO, but software estimation always seemed like an esoteric science. Software developers don't have a magic book to refer to as exist in many other industries.

I've been spending the last couple of days working on putting together some estimates for a bit of work that I am proposing for a freelance project that I am working on and am having trouble getting it down. I'm not experienced with any real software estimation practices and am trying to go from the gut based on my experience but also trying to be a little loose (not too loose though) on the estimates to leave me a bit of room to work.

I read this blog entry http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/ that was linked to from SO and would like to start tracking my estimates at work as well even though I'm not really required to create estimates there.

What tools or techniques would you recommend? Also, how much padding do you usually add in to a time estimate?

Answer 1

Historically, estimating software projects is a huge problem and, as a result, fixed bid projects often end up a disaster for one side or the other. When you don't have accurate historical data on how you perform on similar projects of similar scope, the best you can do is your gut and your gut is probably going to be wrong. Even when you do have data, your often going to be wrong about the requirements in some way or another so you are still going to have problems. Therefore, in these situations the best you can do is charge as much as the market will bare. If the amount you can charge is not enough to make it worth your effort, walk away. The other way you can do it is to bid low and then kill the client with change orders for every little thing. Not pretty either but when you come right down to it that's how large segments of the consulting industry make money.

The agile folks do have some good contrary ideas about this. For example, this article. I do believe these ideas have merit and I have used them with success from time to time. The problem is it can be hard to move a client used to awarding the job to the lowest bidder in the agile direction.

If you feel you have no option but to fixed bid, I suggest padding 100%. That is, if your total estimate for the job is 100 hours, bid 200. That will give you some chance of not getting killed by all the little things you will tend to forget -- acceptance testing, long meetings to pick over functionality, bug fixing after delivery that the client insists are your problem etc. You will not win every project this way but at least you won't go broke working you butt off in a death march for less than $10/hr.

Answer 2

On my previous project, we used an approach that let us finish it on time, so I think it's fairly good. We wrote specs upfront for the whole product but without going into too much detail and with an emphasis on the UI. This was a means for us to get a feel for what had to be done and for the scope of the project. After that we went through the specs and listed all the tasks that had to be carried out (at the level of "create the options dialog layout", "implement getting and setting of options" etc.). Then we assigned time to each task, fairly liberally (keeping the "estimate and multiply by 2" rule in mind) and with a granularity of 0.5 days.

We found that this works out to be fairly accurate. Although the times for particular tasks end up being wrong quite often, you finish some of them later and some earlier because 0.5 day granularity builds up quite a bit of padding.

The other important thing was that there was 2 of us performing estimates, so when we disagreed it often highlighted things we'd forgotten about and allowed us to improve estimates, or otherwise we just took the average of our numbers.

Answer 3

A pointer to a couple of other articles about estimating (that I like), if case you aren't aware of them already:

Joel on Software

Painless Software Schedules
Wednesday, March 29, 2000
http://www.joelonsoftware.com/articles/fog0000000245.html

I like this article, even if Joel says don't read it any more. I've used it. The approach is basically to break the work down into features and then break features into fine-grained tasks that are fine grained enough to understand and estimate (on the level of N hours of work).

Evidence Based Scheduling
Friday, October 26, 2007
http://www.joelonsoftware.com/items/2007/10/26.html

The new "Joel" method for estimates. Probably better, as Joel says, but requires historical data, which you don't have yet.

Answer 4

I like Joel's approach, it is smart and makes a lot of sense. The problem with it is that it is designed for a world that is foreign to me - product development. In product development, you usually can figure out what you need to do first, and then you can estimate what is takes to do it. In the consulting world, we rarely have this luxury, because we routinely need to come up with estimates and a schedule before we get a contract, which means that clients don't pay for the time spent on estimating (we don't bill for proposal-writing, neither explicitly nor otherwise), and detailed requirements are either not available at this time, or they are not reliable. For a small shop like ours, it is rather difficult to develop metrics based on prior work, because every project and every client is different, down to the technology stack. So how can we ever come up with reliable numbers and stay in business doing fixed-price projects?

One approach is to break the overall effort into phases and price them individually. For instance, we do a requirements phase first with defined deliverables and price it separately. We give a broad cost range for the implementation. Once done with requirements, we re-estimate the implementation based on the detailed requirements.

If this is not possible, we have 3 or more experienced people do double-blind estimates on an agreed-upon scope. We take the average, or the highest estimate for each item, depending on what the project can afford.

In my opinion, what separates good estimates from bad estimates is not the ability or inability to determine what it takes to do x - it is the ability or inability to identify the scope of the work while accounting for all the unknown, and an underlying sense of how much of the unknown there is in a particular situation. Some call this "gut feeling" - I call it "experience".

This may sound arrogant, which is not my intent. What I want to convey is that that there is no method, process, or miraculous tool that you can feed with incomplete data and that will spit out accurate numbers. Estimating software projects is a balance act between - getting as complete data as you can with a very limited amount of time and effort - while having some understanding how incomplete your data is.

Answer 5

Check out Steve McConnell's book on Software estimation: http://www.stevemcconnell.com/est.htm That will give you a good foundation.

It has a number of good techniques in it. The company I work for uses the best case, expected case, worst case model that he describes to help calculate a target cost. We generally then have fixed percentages based on construction for things like QA, Go-live support, Missed task buffer, etc.