[iancw]

I recently read Software Estimation (Steve McConnell, author of Code Complete). My main takeaway was to distrust developer intuition and instead build estimates from data. One example is to look at the duration of past projects of "similar size" (still requires some qualitative analysis). Another example is to count the number of distinct "features" or "components," and build an estimate from those. Both of these still require some qualitative analysis. That will be the weak point of any estimate. The goal is to minimize inputs from developer intuition and use as much quantitative analysis as possible when estimating.

[sateesh]

My main takeaway from the McConnel's book has been not to provide an estimate as a single point number (say something like it will be done in 5 weeks) but rather as a range (say something like 5-8 weeks), as providing a single point number would give the impression that it is the target date (while it is not). But unfortunately most of the times all I have got is blank stares when I give estimates as a range and a question why don't you give me the time it takes to finish :(. Wish more number of people who do project management read at least 1st two parts of McConell's book on software estimation.

[DougWebb]

I ran into the same problem, and eventually the only workable solution was to use ranges within the software development group, but to only communicate the high end of the range to the project management group and executive team. Most of the time our projects came in "under budget" this way, which seems self-serving, and sometimes projects we thought we could complete on-time were shelved as being too-expensive, but whenever we tried to give those groups better information (eg: the range) they always went straight for the low-end and gave that out to marketing and other groups as a committed deadline date.

[PaulHoule]

Sometimes I like to say '1d4 hours' or something like that.

[jacques_chester]

I hope you'll keep insisting on giving ranges.

[mmcconnell1618]

I don't think Steve McConnell was suggesting that developer intuition was not relevant. In some of the formulas he suggests for estimation he includes a factor for how accurate the team was in estimating previous projects. Ultimately each developer will need to estimate individual features or other small units.

The other big take away from that book is that estimates should not be a single number but rather a range. If the client insists on a fixed price bid then you start with the higher end of your estimated range and add in something for the risk of a fixed price bid.

[jacques_chester]

One important lesson to take from McConnell's book is that you should not rely on a single sort of estimation. Serious estimators will estimate in distinct ways and then compare the outcomes. If they are widely divergent, it's time to investigate why.