Estimation … Useful Tips

I often receive requests to provide estimates for building huge systems. Typically, such requests only entail the vision of the intended system and the anticipated business value — with limited details on the underlying requirements. The danger in here is that the provided estimates will be used to make important decisions of whether to make the system in house, buy it (if available as COTS), outsource it, or perhaps to cancel the whole initiative in case the estimates are higher that what is feasible.

Definition

To start with, let’s agree that estimation is by definition a judgement, guess or opinion about something. Hence, it it by no mean accurate, yet useful in setting the expectations and helps derive decisions. The estimate can be more accurate primarily if the uncertainties in the business requirements are narrowed down and technical constraints in the environment are identified.

Dealing with Un-Certainties

In Agile projects, no matter how good are the product owner in explaining the product’s vision, or the business analysts in detailing or eliciting the business requirements, there will still be some questions unanswered at the time of estimation. It is only possible to have all the questions answered and reach eventually to zero uncertainties is at the end of the project.

Nonetheless, the team is required to substitutes such uncertainties with assumptions and estimate against them. An example is whether the intended hotel booking system would give a facility to its customers to pay at the hotel front desk at the time of check-in or not. The team should explicitly assume something, if couldn’t be confirmed at the time of estimation, and estimate on it accordingly.

Estimation Team

It is very important to highlight that it is not the sole responsibility of the Software Architects and Developers to provide the estimates. Product Owner, Test Engineers, Business Analysts are all required to participate in the estimation workshops — and all are members of the estimation team.

Estimation Methods

The estimation team has to start by defining the estimate method they would like to follow based on factors such as, the business complexity, urgency of the estimation request or availability of the product owners and relevant SMEs.

One way to do estimation is by Analogy (Triangulation, Benchmarking) with other developed products, specially if they are related to the same business domain (i.e Aviation, Insurance,…). Estimation by Analogy can also be done with the intended product modules to each other. An example to this is if the intended products can be divided in a number of modules, a reference module should be selected and other modules complexities will be sized relatively to that reference module. The reference module then will be estimated using other techniques, explained below, to come up with an estimate to it and later to be reflected to the other modules based on the identified relative complexity.

Another more accurate method of doing the estimation is WBS (work breakdown structure) through breaking down the product requirements into features that can be estimated individually. The two famous WBS estimation techniques are Affinity Estimation or Planning Poker. I see Affinity Estimation good enough for providing estimate early on for the product development with limited available time for estimation, whereas planning poker is much better while doing release planning where the requirements are more refined and the team structure is defined.

The estimation team should also consider assigning priorities for all the identified requirements, as such priorities will help in deciding on the overall schedule by releasing the product into phases with important features first.

The estimation sheet could look like something like this:

The effort estimate unit can be either a Story Point or Ideal Day.

Team Velocity

The velocity of the estimation team should always be readily available as it should have been calculated based on the number of story points the team is able to burn in an iteration. It will be beneficial if the velocity of the team is categorized based on factors like business domain and adopted technology. The velocity will be used as a reference to when it is needed to convert the effort estimation into Actual Man days (Elapsed Days).

Actual Man Day reflects the reality that typically no one can work on one thing all the time without being interrupted, for instance, to help other colleges or for personal matters like phone calls, etc. So if the ideal day is 8 hours a day, then actual day for any team member could be something like 5 hours.

Estimation as a Social Process

It is essential to know that Estimation is a negotiation process with the business owner(s), and relevant SMEs. It is perfectly fine for them to challenge and question the estimates, and the estimation team has to be ready to provide their justifications based on the assumptions they made and the constraints they could identified. If the business owner is not happy with the overall ‘estimated’ duration, she can simplify some of the requirements, remove some of the identified constraints, work on the assumptions to make a call on them or override them with simpler ones. The estimation team accordingly will revise the estimates and submit them again to the business owner and solicit a feedback to see if they are acceptable or not, and so on.

Estimation is a process that involves high degree of communications, reasoning, planning and courage to speak about the constraints in the organization.

Conclusion

Estimation is needed to help decisions makers in taking informed decisions. Estimation team has to define a clear estimation technique to use based on factors like business complexity and availability of the product owners. The estimates should always be supported by reasons and assumptions. Business Sponsors should accept the fact that estimation is not a commitment from the estimation team, nor it is by any mean accurate.