Learn to Estimate
As a developer you need to be able to provide estimates to your managers, colleagues, and users for the tasks you need to perform, so that they will have a reasonably accurate idea of what is necessary in terms of time, costs, technology, and other resources, to achieve the project goals.
In order to learn how to estimate, it is obviously important to learn some estimation techniques. However, first of all, it is fundamental to learn what estimates are, and what they should be used for—as strange as it may seem, many developers and managers don’t really know this.
In fact, a typical conversation between a project manager and a programmer talking about estimates usually goes along the following lines
* PM: "Can you give me an estimate of the time necessary to develop feature xyz?" * Programmer: "One month" * PM: "That's far too long, we've got only one week!" * Programmer: "I need at least three" * PM: "I can give you two at most" * Programmer: "Deal!"
The programmer, at the end, comes up with an “estimate” that matches what is acceptable for the manager, but, since it is his estimate, the manager will hold him accountable for that. To understand what is wrong with this conversation we need three definitions—estimate, target, and commitment.
An estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something. This definition implies that an estimate is an objective measure. It also implies that, being approximate, an estimate cannot be precise, e.g., a task cannot be estimated to last 234.14 days.
A target is a statement of a desirable business objective, e.g.
* The system must support at least 400 concurrent users
A commitment is a promise to deliver specified functionality at a certain level of quality by a certain date. One example could be
* The search functionality will be available in the next release of the product.
Estimates, targets and commitments are independent from each other, but targets and commitments should be based on sound estimates, or, as Steve McConnell puts it: "The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them". In other terms, the purpose of estimation is to make proper project management and planning possible, and allow the project stakeholders to make commitments based on realistic targets.
What the manager in the conversation above was really asking the programmer was to make a commitment based on an unstated target that the manager had in mind, not to provide an estimate. The next time you are asked to provide an estimate make sure everybody involved knows what they are talking about, and you may discover that your projects won’t be late anymore. Now it’s time to learn some techniques…