I was asked recently to help in creating some estimates. Dates were mentioned, features were requested, but generally the information given was pretty vague, as is common with many estimates. So, we start digging. What is needed, when is it needed, in what form is it needed? What does success look like?
There's lots of estimation tools out there. Steve McConnell's Construx Estimate (even though it's written in VB6 and was created in 2001) is well thought of, and can certainly get one jump-started with an estimate. Of course, garbage-in, garbage-out still applies.
Patrick's been using the PlanningPoker technique for estimating lately. It's a useful technique that relies on the folks doing the work also doing the estimating. (Always nice.)
If you take a look at the White Papers section of the Construx website (free registration required, but it's worth it) you'll find a number of excellent presentations in PDF format that are good reminders and primers when dealing with daunting Software Estimation tasks.
Pick up Steve McConnell's book "Software Estimation: Demystifying the Black Art" if you want a nice introduction to the voodoo that is estimating.
I've been reminded of a few important tenets doing this estimating processes.
Know your scope
Negotiating the scope of your project, the features, subsystems, etc. with your business stakeholders is a good first step in getting your head around "what are we really trying to accomplish." User stories and complete and accurate Use Cases are invaluable when trying to nail down how large something is.
Targets are not Estimates
Folks sometimes come up with dates, like "February 2008" as a target for a project to hit. After a while that target date starts getting treated like an estimated date. It's important that everyone on a project remember (or be reminded regularly) that targets are not estimates. If you want to hit a date, you'll likely not know when if an estimate is good enough to hit a target until you start moving far enough into the Cone of Uncertainty.
Ask for Worst Case - then Double That
Jeff Atwood points out, after reading Steve's book, that asking for multiple points (best case, worst case) when asking folks for an estimate is important. He quotes Steve, emphasis mine:
Considering that optimism is a near-universal fact of human nature, software estimates are often undermined by what I think of as a Collusion of Optimists. Developers present estimates that are optimistic. Executives like the optimistic estimates because they imply that desirable business targets are achievable. Managers like the estimates because they imply that they can support upper management's objectives. And so the software project is off and running with no one ever taking a critical look at whether the estimates were well founded in the first place.
This quote nails it for me. No one wants to give a realistic estimate. It's hard and sometimes it's potentially career-limiting. Steve quotes Fred Brooks (who, as a random aside, is the uncle of a good friend of mine from high-school):
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
— Fred Brooks (1975)
A few companies encourage worst-case estimates in the hopes that you can look like a hero if you make it happen. A few companies ago I worked somewhere with the philosophy: Underpromise, over-deliver. It was the founder's belief that this idea was fundamental to making happy customers. It seemed like a good idea, except when you actually delivered and things turned out to be simply: Promised, delivered. Which isn't all that bad, actually, considering that folks say that fewer than 1/4 of projects actually do deliver on time.
Learn From the Past, and Don't Forget It
There's a great slide in the 10 Keys to Success PDF up at Construx that compares 120 projects at Boeing, juxtaposing those that were estimated with Historical Data and those that were done without. Seems obvious, but it's useful to see these kinds of things and "learn from the sins of our fathers."
When estimating based on historical data, however, sometimes people use the historical estimate rather than the historical actual. In fact, a lot of companies don't closely track the actuals. You'll be better off if you not only keep the actual datas, but also compare the original estimate with the actual result in a project post-mortem.
- How do you estimate your projects?
- Do you estimate?
- If so, what tools do you use?
- Do you use Function Point Counting?
- Do you use other techniques?
- What does success look like for your project?
- What's your success rate?
Discuss, dear reader.
Hosting By
Code Camp in Portland is in only 10 days. It starts on May 19th and 20th. There's a good list of sessions so far with topics like Cardspace, XNA (XBox Development), PowerShell, Amazon S3, Silverlight, and many others by a great list of presenters. There's also an even party on Saturday, so be sure to register/RSVP ahead of time.
Hopefully you've taken a look at 
My 
There's a lot of Silverlight coverage out there right now, so rather than covering the basics, we attempted in this podcast to not waste your time and tried to get into some technical detail quickly. I hope you enjoy it.
