The Pragmatic Programmer sums up the problem with upfront estimating about as succinctly as possible:
Initially, you may have only a vague idea of how may iterations will be required, or how long they may be. Some methods require you to nail this down as part of the initital plan, but for all but the most trivial of projects this is a mistake. Unless you are doing an application similar to a previous one, with the same team and the same technology, you’d just be guessing. … This may not be popular with management, who typically want a single hard-and-fast number before the project even starts. You’ll have to help them understand that the team, their productivity, and the environment will determine the schedule. By formalizing this, and refining the schedule as part of each iteration, you’ll be giving them the most accurate scheduling estimates you can.
At a minimum, providing upfront estimates for projects with a high "exploratory" factor (i.e., the domain is not well-understood by either the client or the vendor) should be recognized as extremely risky. For projects with a low exploratory factor (sometimes termed "optimization" projects), an upfront estimate can be considered less risky.
For the former type of project, some planning needs to take place before estimates can be provided.
- Identify who is likely to do the work, and include them in planning discussions.
- Understand the scope of what’s being asked, be sure to ask plenty of questions to gain that understanding.
- From the information gathered in Step 2, a high-level Feature Breakdown can be developed, and from that activity, basic User Stories can composed. Make sure to consider ancillary but common concerns such as setup and deployment.
Our preferred estimation methodology should include team velocity calculation. Once feature descriptions / User Stories are in hand, the process could look like this:
Default approach: After an initial user story creation exercise, run an iteration (or 2 or 3) and estimate velocity from the observed velocity during those iterations. Recognize that a traditional planning/requirements phase often takes just as long as 2 or 3 iterations, so it’s sometimes best just to do the work.
If the project uses a technology familiar to the team members, and the team composition is the same as on previous projects, historical estimates/actual task completion times can be used from those values to provide an upfront estimate. NOTE: Here you need to determine a methodology for tracking historical values.
- Forecast: In cases where where political expediency dictates an upfront estimate, at a minimum, the feature breakdown / User Story exercise should still take place before any estimate is given, and one of the following methods can be used (NOTE: Any number of other quantitative-type methods could be used here, but these, borrowed from Agile guru Mike Cohn, seem good as a starting point):
Expand Stories into their constituent tasks
- Generate two estimates for each story or task
- a "50% probability estimate," meaning that you have a 50% probability of completing the task within the time estimate given
- a "90% probability estimate" meaning that you have a 90% probability of completing the task within the time estimate given, because this estimate includes most of what could possibly go wrong.
- With these numbers, use one of the following methodologies:
- Take the DIFFERENCE b/w the 90% and 50% estimates for each story and square it; Sum those values, and take the square root; Add the result to the sum of your 50% estimates.
- Simply add 50% as a buffer to the sum of your 50% estimates.
Keep in mind that estimating, particularly in Agile development, is an iterative process that takes place during development as well. The advantages of doing so are 1) is to ensure that the all parties, especially the client, are aware of risks to project completion on an ongoing basis, and 2) to narrow the so-called Cone of Uncertainty about estimate accuracy as a project progresses.
Things to remember regarding estimating and project scheuldes:
- Always say "I’ll get back to you" when asked for an estimate, says the Pragmatic Programmer — off-the-cuff estimates have a way of coming back to haunt you. In my experience, when you offer a concrete number in any context, even if you attach all kinds of caveats to it, it tends to take on the character of a commitment.
- Recognize the psychology of and tendency toward underestimation, and attempt to counteract it with reasoned analysis on the importance of investing in the activities described in this document. Steve McConnell says: "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." Scott Hanselmann adds: "No one wants to give a realistic estimate. It’s hard and sometimes it’s potentially career-limiting."
- Be sure not to confuse targets with estimates: Estimating is a bottom-up approach, deriving a calculation of how long a project will take on a feature by feature basis. Targeting is a top-down approach, working back from a desired end point such as a budget of $100,000 or a delivery date of July 1st. Determining team velocity and prioritizing tasks can help you determine what can be accomplished within such constraints.
- Consider the effect of the Cone of Uncertainty on the accuracy of your estimate. Your estimate cannot have more accuracy than is possible at your project’s current position within the Cone.
- Document and communicate the assumptions embedded in your estimate.
- Delays and overruns generally increase toward the end of the project, so don’t assume you’ll make up for lost time as a project progresses — communicate and adjust estimates near the beginning of a project.
- Remember Brooks’s law — adding people to a late software project makes it later; do it only if project tasks are obviously partitionable. In general make sure your estimate accounts for the complexities inherent in increasing the number of team members.
- Make sure you have features initially divided up into a "must have" / "nice to have" / "optional" kind of scheme; and non-essential features prioritized so that lower priority features can be easily dropped in the event of the risk of overrun.
- Related to above, put yourself in a position to negotiate "exchange requests" not accommodate scope-/budget-expanding "change requests" which, while they serve as a good CYA measure for the vendor, tend to produce hard feelings since ultimately they represent extra expense for the client.