Demystifying Estimation for Software Product DevelopmentRajaram ParimiSeptember 27, 2013
Software Development & Software Engineering is a little like following a recipe to cook.
For the Chef(s) (any category of experts ranging from street food joints to house hold cooks), their experience helps them to think & act in a blink. As is the case usually, it is an individual cook who is at the helm of affairs.
When its a bigger group to be catered, the Cooking Team members assume different responsibilities to deliver the taste on-time, on-quality and in sufficient quantity.
Similarly Software Development by a group of specialists is a different ball game versus by a group of individuals (Diverse/Cross-Functional Teams).
To ensure the combined knowledge is uniformly adopted and put to best use, Software Engineering (aka Recipe for Software Development) steps in.
From the seemingly “Unwanted List” of elements of Software Development (from what is otherwise a sort of a creative endeavor), let’s discuss Estimations (the Quantities in the Recipe).
Just as recipes attain perfection over generations, the process of estimation evolves gradually and takes a couple of cycles/years to mature.
Estimation Level & Unit(s)
Based on the phase, the level of estimation is different. With a basic understanding of the overall concept to be built, the level of estimation is of relatively higher degree (possible variance in the range of +/- 50%).
As the concept gets broken down into Requirements, the level of estimation starts to move closer to the possible effort needed (variance comes down to probably +/- 25% range).
At the time of detailing of the individual Requirement(s) into work break-down (Tasks), the level of estimation is closest to the possible effort needed in realizing the requirement (variance around +/- 5%).
If the 5% variance appears as a surprise, lets not forget it is an estimation.
At each phase of detailing i.e. Concept -> Requirement -> Task, there is an increase in the level of understanding, the uncertainty is lesser hence the approximation process gets better.
To be able to map the estimations across the various phases, its better to adopt a unit that can be reffered across all through the endeavor.
When the unit (Days/Hours) remains same across all phases, the approximation improves. The actual planning and execution cycles have to based on the this unit as well.
amount of detail needed across the various phases of the software development life-cycle is different
estimation at various levels is done based on the understanding and expertise of the concept, skills and other parameters involved in the building and delivery process
effort needed (Estimate) and duration to get the software built (Duration) are two different aspects
unit of estimation (Days/Hours) must not be mis-interpreted
sum total of All Tasks across All Requirements has to add up to the estimate of the Total Concept
Accordingly different teams approach estimation process differently based on how much detail they are working with.
The estimations can be different per individual team member given the relative skill match.
However for the combined endeavor, the overall estimation has to be based on the average skill of the team involved in building the software.
This calls for Normalizing the estimates to ensure, they stay applicable for the whole team.
The process of Normalizing is often based on the build-up of the functional/domain knowledge and the involved technical skill-set.
The case of a team member with [High Technical Skill + Moderate Domain Skill] is different than [Moderate Technical Skill + High Domain Skill] or any other applicable combination of these factors.
Based on the team composition, the applicable Normalizing has to be applied to keep the estimations reference-able. (The impact due to the newness to domain or the technical skill in terms of applicable learning curve is a matter of planning.)
the Quantities (Estimations) thus have a crucial role in the Recipe (Software) to lead to a tasty delight.