This had been one of my longest meetings thus far. You see the team I was in, I was the only developer. The rest of the team was made up of different professionals including designer, UX specialists and animation engineer. Each of us was giving an update on what we were working on. From the buzz of the meeting I heard my name mentioned and the boss asked me “So Chencha how long will it take to enable applicants to use their existing profiles in their applications?”. Without much thought I immediately replied “five days”. The boss typed my response into her mac and moved on. Five days later an email comes in from another team lead asking how do they use the feature that allows applicants to attach existing profiles.
Since then am much wiser and would almost certainly never commit to a schedule just like that. Yet this scenario plays out in software agencies everyday. The client, the manager and sometimes fellow developers expect an immediate answer in days of when something can get completed. Giving an off the cuff answer to this kinds of queries is usually a bad idea.
In this entry, we will explore why this type of estimation is cancer to your project planning.
You will not remember to factor in less visible activities
Asked to give an estimate, most developers will think of the classes, methods, services and other such technical considerations. What will not immediately bubble up will be things like: Time supporting the current version, meetings, organizational commitments, emails etc.
That is, unless you keep a detailed log of all activities, you are highly likely to forget the more mundane ones. The problem is that even mundane activities take time to get done.
It would be wise to keep in mind H.L Mencken quip
For every complex question. There is an answer that is simple elegant and wrong
With this then it is more important to ensure that the estimate you give is correct rather than it was given quickly.
Commitments are made to others
Unfortunately, many of us in the industry do not differentiate between estimates and commitments. By this I mean that whenever you say “I estimate that this task will take 3 days”, what the client hears is “I commit to getting this done in 3 days”.
In the entry Estimates, Targets and Commitments I delve more into the difference between the terms and how mixing them up comes back to bite you.
For this entry it suffices to say that the estimates you give as a developer feed into the plans of the rest organization. With so much weight, the opinion of how much time a task should take should not be done in a rushed manner.
Devaluation of the proper process
Typically, the estimation process is three step:
- Establish the size of the user story relative to other stories
- Establish how long it takes to complete one story
- Schedule the stories into sprints
Compared to just spitting out the first value that comes to your mind, this process takes a heck more time.
Yet this method still remains one of the most effective ways of arriving at dependable estimates. When you shortcut the process you end up unconsciously training the client to expect immediate estimates. This then ties you into a vicious cycle where your estimates are wrong, so the client asks for another set of estimates, which you then give off the cuff and they end up being wrong and the process repeats ad nauseum.
Accuracy goes off the window
By giving a precise value such as “this will take 3 days” you create the illusion of certainty. In reality, accuracy and precision do not always go together. Eg if I tell you “This will take me a week or so to complete” vs “This will take 5 days to complete”. Which one do you think is more precise? What about more accurate? Obviously the first one is less precise but will likely turn out to be true, the second one is more precise but if anything comes up and I no longer can deliver in five days then the estimate is no longer accurate.
With this in mind, you should then remember that estimates for user stories are given as a triangulation of the estimate given for other similar stories. This eliminates the need to be extremely precise since the estimates are relative.
Traditionally, it has been advised that you give a range such as “This will take 3-5 days to complete”. Personally I doubt the effectiveness of this strategy. Chiefly because being humans, we tend to conveniently forget values we don’t like. So you tell your project manager this will take 3-5 days but what they communicate to the client is that it will take 3 days. That is the range gets collapsed to a single value somewhere in the communication chain.
Do you give off the cuff estimates in your own organisation? Talk to me in the comment section below or on my twitter @jchex