People need estimates. So they can predict how much software will cost and how long it will take.
People need umbrellas. So they don’t get wet when it rains.
Although, some people don’t need umbrellas. They have awesome waterproof jackets with hoods. They have solved the problem of “how do I stop getting wet?” with a different solution to the humble umbrella.
People need to know what time the trains are running so they can plan their trip to work. Some people do not need to know this because they take the London Underground, where trains typically arrive every 2 or 3 minutes.
What’s your point, Neil, you might be asking? My point is that when people are debating against the #NoEstimates movement, they always seem to gravitate toward the same two arguments:
To the first point, people only need estimates if we determine that the only solution to the problem of wanting to know “how long and how much” is to make a guess. People who have found other solutions to that problem do not need estimates.
I now wonder: just because the people who still need estimates have not discovered any alternative solutions, does that mean they need estimates or that they think they need them? Or simply prefer to use them over other solutions?
People do not need umbrellas. They need a way to stay dry on a rainy day.
To the second point, I categorically want to put an end to the myth that #NoEstimates equates to #NoPrice or #NoDate. If you read my previous blog posts on the subject or read my tweets you will hopefully understand that my point is the absolute opposite. We DO need a price and/or a date. The only difference is how we arrive at those things.
With estimation, you guess one or both of them (and, in doing so, have a stab at scope too — otherwise what are you estimating?)
With #NoEstimates you set the price and/or date, either through experience and choice (for e.g. setting price/date for the kind of work you do regularly, with a fixed team and cost) or through a real budgetary or time constraint (e.g. “I’ve only got $100k, what can we build for that?” or “The Australian Open starts in 3 months so the Aus Open app needs to be ready to go live the day before”.)
You then incrementally and iteratively deliver, setting mini-constraints within the wider constraint that breed creativity, innovation and predictability of delivery, and have a flexible working and payment arrangement with the customer.
People need certainty about what they will get and how much they have to spend. Unfortunately there is no certainty in software design and development. However, I would argue that #NoEstimates gives greater certainty than estimating does.
When estimating a date or cost you are creating uncertainty around those things, because you are guessing. You are saying “we’ll deliver somewhere between here and here”. However, if your delivery date and/or cost is set by a real constraint, as advocated by the #NoEstimates approach, you have created certainty around those things.
Yes, you may decide to shift the date/cost as you get closer to the initial figures, or once the customer decides they are happy with what they have. You have been delivering frequently and learning about what you are building. You have been creating data, such as throughput and cycle times, and using heuristics and slicing to reduce work increment size, so informed decisions can be made along the way. But you will only go beyond those initial figures if the emergent value of what has been built, and other data you have gathered, suggests that you should. Scope remains uncertain whether you estimate or not.
People still need 500-page business requirement documents. People still need separate test teams and development teams. But there are alternative solutions which may render these needs unnecessary. The alternatives to estimation are real, both at the project and the portfolio level, and are being used by many people across the globe in varying sized businesses.
All I ask is that we consider those alternatives and do not stop searching due to need.