Estimation for Agile Projects
While there has been much already written on agile estimation, it is an area that comes up time and time again. This article will cover the big picture view of upfront estimates and ways to engage more stakeholders in the estimation process.
First of all we need to understand that estimating software projects will always be problematic. It does not matter if it will be a traditional project or an agile one; software development projects are unique (we do not repeatedly build the same system) and the evaluation difficulties that make gathering upfront-requirements tricky also make scoping and estimating hard, too. So approach the problem conscious of the issues and limitations of any approach; keep in mind that early estimates will have wide ranges of variability.

As shown by Barry Boehm’s estimate convergence graph (above), at the time of Requirements Specification estimates are only likely to be in 1.5x to 0.6x of the final project cost range. Calls for ± 10% are just not realistic on most software projects.
Next we need to accept that at the start of a project, the estimation approach will be similar for agile or traditional projects. By this I mean we have very little to go on, probably no productivity data for the exact team undertaking the work and only a course grained view of the project scope and complexity. Agile
Please log in or sign up below to read the rest of the article.
ADVERTISEMENTS
|
"How much deeper would the ocean be if sponges didn't live there?" - Steven Wright |




