Fog Creek Software
Discussion Board

Book Recommendations on Software Effort Estimation

I am nearly 4 yrs experienced in this field as a developer. I am going to start estimation for some projects.
I have never done this before.

any book recommendations on effort estimation for a beginner are helpful.

developer going to be analyst
Sunday, July 25, 2004

Well, you can start by reading Joel's articles on the subject.

There is a decent article on the subject at my blog.

Then you have Steve McConnell's books.

Ready...set...go!  ;)
Sunday, July 25, 2004

Search this forum. There are plenty of links relating to this subject.

Here's a recent thread:

Sunday, July 25, 2004

Estimate = Wildest Guess * 3

Monday, July 26, 2004

You forgot the "And bump up to the next unit of time."

If you think two days, say six weeks.

Chris Tavares
Monday, July 26, 2004

craig you are a joker

be serious
Monday, July 26, 2004

I thought you work it out by doubling your initial estimate, then double again because your superiors will insist on getting things done in half the estimated time.

Monday, July 26, 2004

Hmm.  Fundamentally, you are trying to answer the question "When will it be done", right?

A) Clarify what "IT" means.  First, are the specs complete?  Correct? 

Do you know my experience that you will encounter scope creep?

Have you done similar projects before?

This should give you some impression of the "Shit, I forgot ..." factor.  We'll call this X, and score it from 0.25 to 4.  (0.25 = we know what's going on, 4 = We Have No Clue, expect the unexpected.)

B) Clarify what "Done" means.  Code Complete?  Throughly tested?  Tested and Bug-Free?  (Or "No major issues"?)  Documentation Complete?  Burned to CD?  Shipped to the customer?  In production?  Etc.  Consider the things you are likely to forget when making the schedule.

C) Use something like Joel's Method for functional decomposition.  Consider the things you are likely to forget when making the schedule.

D) Do you have > 1 person on the team?  Resolve the dependencies.  Add slack between dependencies, not by giving people time with nothing to do, but by re-ordering the tasks.

E) Consider risk -

Risk increases the "oh, shit" factor by from 0 (no risk) to 2. (Heavy risk)

F) Create your schedule with B, C, and D.  Call this length of time in person months "X".  Then add in an additional buffer that is equal (X+Oh_Shit_Factor).

G) If management doesn't believe in buffers or slack,  rationalize your schedule to take out the buffer and increase each task.  It's the same end date, just a different gannt chart.  This gives you two end dates:

K) End Date When Buffer Starts
L) End Date After Buffer

You can call these the "Internal, Programmers-Only Goal Date" and the External Committ Date.

Two good books about this are "Waltzing with Bears:  Managing Risk on Software Projects" by DeMarco/Lister and "Critical Chain" my Eli Goldratt.

My best piece of advice is not to just take my ideas and run, but instead to read a heckuva lot of books.  Those two, anything by steve McConnell, anything by Spolsky, Etc.  When you have a lot of tools in your tool box, the task seems to get easier ...

Regards, (Matt H.)
Monday, July 26, 2004

Above, Buffer is:


Not plus.  My mistake. (Matt H.)
Monday, July 26, 2004

There are some books you can get on Function Points. That is a reasonable metric for predicting how long it will take to develop stuff.

IBM used it for determining that the Denver Airport baggage handling system would take 4 years to develop. The marketing/sales droids screamed that it had to be done in 2 years, and promised it to the airport that it could be finished in 2 years, because the airport would be finished then. The baggage handling system took 4 years to make. Was the Denver Airport baggage handling system finished on time or 2 years late?

Monday, July 26, 2004

I would like to recommend Steve Mcconnell's book 'Software Estimation: Demystifying the Black Art'.

But the book is not out yet...

and he can't give an estimation when the book will be finished ;)

Out of range error
Monday, July 26, 2004

*  Recent Topics

*  Fog Creek Home