The most foolish way to estimate the labor involved in a software development project is by assessing individual features. Almost for every project, one has to fill out tables for the client like “feature – labor estimate”. It would be fine if these features were actual work packages that are more or less independent. Frequently, one encounters non-functional requirements, quality requirements, performance, and interface requirements. Estimating how many working days are needed to meet, for example, quality requirements or performance requirements separately from other functional requirements is a thankless task.
IMHO the only correct method for estimation is to break it down into phases and work packages with measurable outcomes and to estimate by work packages. In this case, a feature might be the result of work from different packages. Quality requirements and other non-functional requirements are merely constraints.
Work packages are activities aimed at achieving measurable outcomes – be it features, design mockups, documents, training, or implementation. If one were to estimate each feature, logically, one should collate the labor from the entire project lifecycle – from designing the architecture, the interface, development, fine-tuning this interface to going live. This can be done, but as a byproduct of what I consider, IMHO, a normal estimation by phases and work packages.
Phew. Just had to get that out.
Hi, I'm Rauf Aliev. 