For years I thought I was a poor developer because I could not estimate well. Spending more time and effort on estimation did not really help either. (Predictability Paradox). One day it struck me that may be this whole practice is flawed and I’m not the only one who finds it difficult to estimate. Its been 6 years now and I’ve never looked back again.
Estimates are a hang-over from the waterfall world. For the last 6 years, I’ve been very happy and successful building products and delivering projects without all the estimation related ab-ra-ca-dab-ra. No more real-time, ideal-time, story point, function point; non-sense. I’ve realized the key is to focus on the flow of the deliverable and not whether your are delivering according to the estimates.
It turns out that most people don’t like estimation, but they do it because their Management needs it. Usually when Management asks for estimates, my question to them is how will this estimate really help? What if I said 6 months and I delivered in 12 months? What will really change? And if something really changes, will you do something about it now or you can handle that a little later? Again do you really need to know now or you can watch the rate at which we deliver useful features and plan those other activities later? And BTW how many times have your team delivered according to their estimates? If they did, did the thought ever cross your mind that the estimates were heavily buffered? (The bloat effect!)
I also commonly use the “throwing the dice” exercise to educate people about estimates. In this exercise, I ask the estimate obsessed person to estimate how long it will take them to throw 3 consecutive Six on a dice. Guess what, the person says how can I predict? Well there is probability theory and other great work that can be used, but ….
In most cases, it turns out that Estimation smells of lack of trust (because of past experience) and urge to push your risk on to someone else (so that you can point your finger to someone else). IMHO Management emphasizes on estimates for wrong reasons, rather than any true value those numbers provide.
Another thing to consider when we talk about estimates is, I can take 1 day to build a login screen or I can take 1 month to build it. The real question is how much sophistication your users need? In most cases you don’t know this until you see your users (at least proxy users) use the feature. So why estimate upfront and miss the opportunity to collaborate with your users?
When you start thinking about sophistication, then all of sudden you start thinking from a budgeting point of view rather than estimation. Most people get confused between the two things and interchangeably use one for another as if they were the same concept. What I see myself doing is regularly budgeting features by playing around with the sophistication knobs on each feature. This is yet another way to have your scope negotiable.
When we talk about estimation and it’s evils, I guess you must be aware of Student Syndrome.
So think about the real value of estimates and the effort spent on it. Is it really worth all the pain?
Does this mean we should embrace uncertainty? Yes and No. To some extent you can’t really predict the future so go with the flow. But on the other hand, you setup short (really short) feedback points to correct your direction and hence keep the chaos under check.