Software Development & Software Engineering are a bit like Cooking & Recipes.
For the Chef(s) (any category of experts ranging from street food joints to house hold cooks), their experience helps think & act in a Blink.
Further in most cases, its an individual cook who is at the helm of affairs.
When its a bigger group to be catered, the Cooking Team members assumes different responsibilities to deliver the taste on-time, on-quality and sufficient quantity.
Software Development by a group of specialists is a different game versus by a group of individuals (Diverse/Cross-Functional Teams).
To ensure the combined knowledge is uniformly adopted and put to the best use, Software Engineering (aka Recipe for Software Development) creeps in.
From the seemingly "Unwanted List" of elements of Software Development (from what is otherwise a sort of a creative endeavor), lets discuss Estimations (the Quantities in the Recipe).Like the recipes get perfected over generations, the process of estimation takes a couple of cycles/years to mature.
The process evolves gradually starting with:
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 surprises, lets not forget it is an estimation.
At each phase of detailing i.e. Concept -> Requirement -> Task, there is an increase in understanding, uncertainty is lesser hence the approximation process is better.
To be able to map the estimations across the various phases, the unit of estimation has to be agreed.
The unit (Day/Hours) has to remain same across all phases, the approximation improves.
The actual planning and execution cycles have to based on the this unit as well.
Estimation Approach
- 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
Normalizing Estimation(s)
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.
bon appetit !!!
