*********************************************************************************************
Haggle ˈhaɡ(ə)l/ verb - gerund or present participle: haggling dispute or bargain persistently, especially over the cost of something.
**********************************************************************************************
Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available
**********************************************************************************************
After spending some time to thinking about what will be a good start for this paper I finally decided to just put meaning of two words haggle and estimation. I am sure all of us at some point of time in our IT profession have been part of hopeless discussions either asking or providing justification on an estimate which someone thinks is higher than imaginary figure or is less than this imaginary acceptable figure. I am sure many of us will not agree to comment suggesting it is a hopeless discussion. People passionate about having these discussions will ask, what about governance and checks which are required to ensure that we do not overspend or under-spend allocated budget? I don’t dispute that we should not have any governance or checks around estimation process, cost plays a very important factor in success or failure of any delivery so it needs to be questioned and agreed. However it needs to be done with some rationality and should not end up in a haggling exercise similar to making a purchase at flea market.
Consider a typical project estimation review meetings in your organization, my guess is that it will involve people from different business units, architecture teams and technology products sitting together and reviewing the effort (doesn’t matter if it is man days, hours or dollar value) for various projects. Depending on the budget at stake people involved in discussion could range from CEO, Directors, Vice Presidents, Product Leads etc. It is a simple rule, more money more scrutiny hence more questions all this translates to more time spend on examining estimates. Everyone comes to these meeting with a figure in mind which is based on individual knowledge and what is reviewed is an estimate which in most cases is submitted by an expert based on vast wealth of knowledge gained through years of work.
These review meetings are supposed to ensure that whatever number has come out of estimate exercise has considered everything that is required and is worth spending compared to benefits that will be delivered by the change. However in high number of instances these end up in discussion on confirming that number that is estimated is the actual number and why can’t it be reduced further to an acceptable figure. Worst is that most of the times these questions are raised by the person in group who has no idea about what that estimated number is going to deliver. Laughable are situations when someone is asked to justify why estimate are less than an imaginative figure.
It is like IT professional being asked to review an estimated provided to construct a bridge on a river. Normal human tendency is to probe others so what this IT professional will do is try to use his frame of reference which probably might be to create an application for Android phone which has been downloaded by 1 million users. What type of questions can we expect in this review meeting… Why can’t you construct the bridge in 1.5 million dollar instead of 1.7 million dollar?
I call such discussions hopeless is because no one is going to win these debates and what is lost is time which translates into cost for all people participating in such discussions. Sometimes I wonder if anyone has performed any analysis on how much money is wasted in having such discussions. I will like to reiterate that we should blindly believe the person who is performing estimates we should definitely question the person who has estimated. But what should be scrutinized is what is behind the numbers and not number value itself. And most important should be scrutinized by someone who understands the underlying complexities on whatever is being estimated.
But now things are changing for good and most of the organizations have realized that instead of wasting time in estimation we should invest money and time in delivering benefits. And AGILE estimation approach is a very positive step in this regards. I think AGILE estimation method helps to resolve two of the main problem we have been facing in waterfall estimation-
- Smaller Chunks – In waterfall model we estimate for a fully furnished house with all fittings completed, but in AGILE what we estimate is each room separately. Though I am still taking baby steps in AGILE delivery world, however I feel user stories are an excellent way of compartmentalize requirements. They provide small and manageable chunks to estimate and deliver. Someone mentioned to me that we should make estimate “palatable” in other words should not give a heart attack. Estimating user stories is a good way of making estimates tasty. I am sure we have encountered situations where requesting for 50,000 for one thing makes life a hell however requesting 5,000 for 10 things is like walking on roses.
- Removes Black Box – In standard waterfall process requirements are written by person A in BRD, person B provides estimates based on BRD and later person C questions the estimates. Problem in this model is that all the three person work in a black box just handing off expected end products. In such situations if estimates are within an acceptable range everything is smooth however if it is not then we get into long discussions with all form of WHAT, WHY, HOW and WHERE questions. On other hand AGILE estimation process promotes is that A, B and C all work in collaboration during estimation as well. Here again person B is going to estimate however not the differences is person A and C are aware of what that estimate is based on.
- Comparative – One of the most important reforming estimation technique promoted by AGILE delivery is that it is not re-inventing the wheel every time. Unlike waterfall model in which every project is estimated as an individual entity, AGILE estimation is based on comparative estimation. Past experiences and learning are not lost, every user story is estimated compared to other user stories within the project or to ones which are already executed. So estimations becomes an apple to apple comparison exercise which reduces time significantly.
- Reduces Re-estimation – one of the draw-back of waterfall model is to estimate for all or none at first. One of the reason why everyone is so much focused on ensuring estimates are as close to actuals is because budget approval are taken based on estimates. And these numbers are based on All-Or-None approach. In number of instances what happens is after realizing that estimates exceed acceptable range we start to figure out how to break requirements into phases and look at famous MoSCoW categorization of requirements. And after investing lot of time in this re-estimation is done and this cycle keeps going on unless the estimates come within acceptable range. AGILE on other hand avoids this because user stories breaks business need into small manageable chunks for estimations and based on that these user stories can be prioritized and delivered.
I will like to end this paper on a simple note that estimate is just an educated guess whatever scientific method and automation we build around this, it will not turn it into a true reflection of actual effort. So our focus should not be in ensuring that estimates are always palatable but to deliver benefits what underlying change will deliver.
