Risk Adjusted M-L-M Estimation for Software Projects

How do the estimates compare with the original thought about the size of the project? Is the scope of requirements right or did the end-users go crazy with jazzy new features that they always wanted but never needed? If the size came up within the expected range of the original guess, and there is budget available and all signals are positive, then it is time to make the estimates a bit more concrete.

Just applying standardized sizes to four buckets is not enough to have an accurate estimate of how big and more importantly, how long a project is going to take to develop and implement or deploy. It is necessary to estimate each functional story for its own merit and not as part of a bucket.

Earlier in the article I mentioned about how developers never agree, sometimes even with themselves. One piece of functionality may take different lengths of time to develop depending on development environment or the skill and experience of the developer. The developer may also need to consider whether there is already a framework available to exploit, code that can be reuse, and development processes, such as pair programming, as well as other dependencies.

All estimates need a minimum, a likely and a maximum. What if everything goes right, the developer has the right skills, the environment is perfect and the momentum is great? Minimum estimate to develop a functionality is rarely used, but is always good to have, if only just to justify the likely. Maximum is when everything gets delayed, the worst case. Likely is ultimately the developers’ estimate.

The formula to use, to calculate the average of these estimates, should be weighted toward the maximum. (Minimum + likely + 4*maximum) / 6 gives the planned estimate for each of the stories. This formula will represent the development effort for the project.

Not all stories are straightforward. Some may be simple, while others quite can be vague. Each story should be assessed for risks and adjusted using the above weighting to accommodate these risks. For instance, if the risk is high for a story, then the formula could multiply the maximum estimate by 6 rather than 4 and the number could be 2 for relatively low risk stories.

How to assess the risks and adjust the estimates, is an essay by itself, and is beyond the scope of this one. The above estimation process only takes into account the development activity. Quality assurance, business analysis, project management, as well as other activities associated with software projects, not to mention infrastructure requirements and software licenses, all affect the cost of a project and should be carefully considered.