I am absolutely TERRIBLE at estimating the time it takes for project development. I was hoping experience would change that. If seasoned veterans still have issues (Jeff?), is there any hope for me?

"You'll also notice that both the Best Case and Worst Case estimates are higher than the original single-point estimate."

Huh? It seems to me that 10.5 is less than 11.25.

"Huh? It seems to me that 10.5 is less than 11.25."

Delta rose from 0.5 days to a whooping 0.75 days... Which I agree doesn't sound all that impressive in the whole context.

Here's a suggestion to use when estimating *someone else's* time:

Estimate = (1*Best case estimate)+(2*Realistic estimate)+(4*Worst case estimate) / 7

It weighs the estimate towards the worst case, but takes the best case and expected estimate into account.

As for your own, if you've been in the game for long enough, you should know them (hmm... could those archived timesheets have some value after all?). Of course, this may mean that you know that your own estimates sucks (even if its through no fault of your own). In that case, start with your own formula and tweak it 'til it works.

Oh, and good luck :)

PS, why is b-l-o-g-s-p-o-t objectionable content?!

Yeah, I like Steve McConnell, but the given data doesn't really back up his sweeping statement there. Three items were estimated to take less time in the best case, one was estimated to take more time in the best case, and six were estimated the same. So I think it supports the statement that single-point estimates tend to be best-case estimates, but I don't think it supports the statement that thinking about the worst case /always/ makes one gloomier about the best case.

How I estimate the time it will take for a project :

Estimate = [very first estimation] * 2 * 3

At my old consulting firm our project managers would double our estimates.

I try to give high-end estimates with a degree of certainty attached. "I'll be able to complete this in 100 hrs with 95% certainty."

One of the most important lessons my first programming mentor taught me is that estimation is harder than developing. He had me estimate a project, then worked with me to understand just how optimistic I'd been.

As with your previous post on maintenance work, I believe that junior developers should have to do estimates early in their programming careers. There are two possible feedback mechanisms - work with them to see where they've gone wrong, or secretly pad it for them and then review their estimate with them after the job's completed.

I read the book too. I liked the diversity of approaches he covers and how he suggests using at least two methods. If they converge, you have more confidence in those numbers; if not, you should investigate why and address it.

My favorite quotes:

page 14: "Accuracy of +/- 5% won't do you much good if the project's underlying assumptions change by 100%."

page 18: "Avoid using artificially narrow ranges. Be sure the ranges you use in your estimates don't misrepresent your confidence in your estimates."

page 36: "The only way to reduce the variability in the estimate is to reduce the variability in the project."

page 132: "Do not address estimation uncertainty by biasing the estimate. Address unceartainty by expressing the estimate in uncertain terms."

Yes, I took notes.

> Huh? It seems to me that 10.5 is less than 11.25.

I think McConnell is referring to the fact that the best case got "bester" and the worst case got "worster". That's the goal--better estimates.

> PS, why is b-l-o-g-s-p-o-t objectionable content?!

Because I get 3-4 new spam *.blogsp0t trackbacks EVERY SINGLE DAY. Cleaning it up is very tedious. I apologize to anyone who is incovenienced, but until blogsp0t (a *GOOGLE* company) cleans up their spam act, I have no choice..

As a program manager, my estimation method would be to take the "best case scenario" and multiply it by three. This is my within-team estimate that I will use to set the team working to.

I will take the worst-case scenario and multiply it by eight. This is what I will tell management. Then, if it looks like the team will be done early, *I* look like a hero to management.

Johanna Rothman has a lot to say about project estimation. This podcast is a pretty good starting point:
http://www.itconversations.com/shows/detail392.html
as is her blog:
http://www.jrothman.com/weblog/blogger.html

Ugh, I can't believe how many commenters are repeating the "take the estimate and multiply it by 'X'" approach. That's exactly what the book says *not* to do.

"Huh? It seems to me that 10.5 is less than 11.25."

I was also puzzled by this, so I looked it up when I got home. The edition I have actually reads "If you examine the estimate for Feature 4, you'll also notice that both the Best Case and the Worst Case estimates [...]"

'Feature 4' corresponds to 'Delta' above, which clearly does increase...

If you start with a guess, factoring in another guess is not materially improving your situation.

Matching planned work with historical measurements would perhaps be a beginning strategy. Surely McConnell has something more to say on such *real* estimation.

orange

Touché.

Funny, as I'm reading this book as well. Estimations are not a developers strong skill, I've found (including myself).

We're also going through Code Complete as a group at work which is interesting (this will be my second time reading it).

Actually I think three point estimation is even better than 2 point estimation. We have a tutorial on this on our page (its a quite long read as it contains a little stories and some explanations in the beginning):

http://www.visionarytools.com/decision-making/3-point-estimating.htm

I always use:
(best case + 4 * best guess + worst case) / 6

This is surprisingly accurate, and I think it is a standard formula (part of Pert?)

Late to the game here, but I'm surprised that estimation is still primarily based on guessing. How possible would it be to develop metrics based on historical data and use them along the lines of "The last time we had to create a feature/product/method/whatever like this, it took time." Assuming one could come up with an apples and apples comparison, of course.

I'm sure that most people would say "Well, that was last time, but THIS time we're going to ..." and fantasize about some super-improved process that's going to make everything go way better this time around. Historical data suggests, however, that this won't be the case ...

Whatever

I agree estimation is a tough problem, and I also like Steve McConnell's work.

Obviously, if you (or your company) has previous experience in a similar project, this is the best way to go. In any case, I've found the most important thing to do is to break down estimates as best you can. Keep breaking them down until no tasks have estimates greater than 3 days. I find this forces you to think about the project in detail, and avoid big vague estimations.

I also find it useful just to estimate raw development time (with some self-testing and/or unit testing, depending on what you do). Then add a risk percentage (ideally proportional to how risky the project is, and/or how much variance is in your raw estimates). Finally, add a further percentage for (integration/system) testing, documentation, optimization, sickness/holidays.

So far, this has worked well for me, but it requires familiarity with the project domain and the programmers.

(And I like Steve's advice of gradual refinement. In practice though, it's a hard sell to management.)

estimation is done due to uncertainty
the only way to improve estimate is to reduce uncertainty
clarify requirements
define scope
small project length

I think the best one-word key ingredient to accurate estimation is experience. Sure a lot of the other factors affect how well you're able to pinpoint an estimate, but having the ability to recognize the scenario you're in and apply lessons learned to the entire issue is the best way to really get more accurate over time.

good practis.

If you start with a guess, factoring in another guess is not materially improving your situation.

Matching planned work with historical measurements would perhaps be a beginning strategy. Surely McConnell has something more to say on such *real* estimation.

It is really helpful to be able to provide an estimate that is as truthful and realistic as possible, particularly for the developer(s) that will ultimately do the work. It has been my experience that when I've understood the problem domain and the requirements were not subject to considerable fluctuation, I could, given time to complete the estimation task, provide a reasonably accurate response to the level of effort and basic timeframe for development.

I have been in situations, however, where the requirements were an evolving beast and the problem domain sometimes was not completely known at estimation time. Despite this state, management/marketing were insistent on having estimations and that proved to be considerably more difficult. When the requirements are in considerable flux, the task of estimating software development degrades into an exercise of pulling numbers from one's nether region. When management then hand-waves at the number of unknowns and takes those "estimates" as the gospel truth, it puts the developer(s) behind the eight ball from square one and creates an environment where software and management are at odds with one another. Such an environment encourages short-cuts to meet unrealistic deadlines, often requires considerable overtime by software to meet milestones, breeds discontent in the ranks and likely results in a product of questionable quality.