If numbers come into play then quantification is implicit. Most of the projects I begin, I start estimating use cases in “High, Medium, Low” or “Small, Medium, Large”. Before the development starts we need to know how long something is going to take, hence we estimate. When we arrive at an estimate and put a schedule in place, subconsciously every one gets tuned to the numbers.
The numbers help in planning and helps the first release goes through; then the economical activities begin. Questions start arising like ‘Why two use cases estimated to be of the same size when one of them have fewer tasks?’ or ‘Why did two use cases with similar sizes take different times to complete?’. The completion of the use cases is what shows up as progress and slowly an illusion is created that the reduction in estimate is equal to the money saved. This leads to addition of scope similar to salami slicing.
The effect of salami slicing becomes visible over the course of time and developers begin to compensate by increasing the estimate. This vicious cycle leads to inflation and deflation of estimates, which in turn affects the project management’s ability to predict and plan. Quantitative/Objective measurement gives an illusion of control but will eventually affect the team’s ability to deliver value because there are lots of parameters which affects how something can be done; attaching a number to it will create those numbers to behave like currency. When we have something like a currency then we have economics.
Should estimation be very accurate?; No, it is like saying that with all the historic data and current conditions, we will be able to predict the outcome of cricket matches accurate to the number of runs scored. We should have estimates only as a guideline for planning and acknowledge that pin point accuracy will never be possible. Productivity is a result of so many factors and trying to assess that with a single number will result in expending time and energy away from productive tasks.
Novi's 