Why software estimation is an ongoing process

Maybe you recognize the following situation: you are asked to estimate a new project. So you dive into the – often incomplete and unclear – specifications. After trying to understand the specifications and hopefully having a lot of meetings with the customer and end users you create an neat Excel spread sheet with a work breakdown structure, and some formulas and nice estimation figures. You did a great job! Well done!

Next the project starts, and the project team now has the challenge to deliver software meeting up with your estimates. However, a number of issues surface. The project team looks at the specifications and might interpret these differently. Or even worse, they, or the customer, might come up with new requirements. Or just make different assumptions on the complexity of the software to build. Or the technology used is not as straightforward as people assumed – often the software architects. There goes your estimate.

Challenges in estimation

There are a number of challenges when it comes to estimating software development projects that arise from this small anecdote:

Initial estimates are hard. Making an initial estimate for a project is hard, as requirements are often incomplete, unknown or difficult to grasp.
Requirements changes. During a project, new requirements come up, requirements change or are even dropped.
Technology bias. Technology often turns out to be more complex (and sometimes simpler) then vendors and architects make us believe. Implementing software in a service oriented architecture is a good example.

Concluding: estimation is not an simple activity that needs to be executed at the start of a project. It is ongoing business. Not only do we need to make a plausible initial estimate of the project, just to start the work. New estimates need to be made when changes to requirements, complexity or technology surface. Why? Well simply because these changes will effect the project planning. It’s better to be aware of such effects as soon as possible.

Versatile

Therefore, the techniques used to estimate the complexity for software development projects need to be versatile. Think of:

Transparent. Creating an estimate should be dependent on some high-brow certified expert, but should rather be a team effort, accessible to all team members.
Swift. If creating an (improved) estimate takes a week, or even several days, it is unlikely that new estimates will be set up during a running projects. There just isn’t the time to do so. Hence, your project will not benefit from new insights. However, if re-estimation only takes an hour, or a few hours, it is not unlikely that this becomes a natural step in your iteration, e.g. at iteration start or end.
Repeatable. Two different estimates for the same project should be equally sized. That is, they don’t have to be equal, but they will have to be in the same range.
Unbiased. Estimates made by people with different levels of expertise, or different technological backgrounds should not differ too much. Estimates must be unbiased. It is therefore of great importance to use an abstract scale to estimate complexity, rather than estimate effort in hours (or even ideal working days).

Smart estimation is the technique where the complexity of software development projects is estimated based on smart use cases. Smart estimation uses an abstract scale (1, 2, 3, 4, 5, 8 and 10), and smart use cases can be stereotyped according to the functionality they execute. The factors above, such as transparency, swiftness and bias can be met using smart estimation.