Response to "People Need Estimates"

This is a response to Neil Killick's great post http://neilkillick.com/2013/04/18/people-need-estimates/

The essence of that post is this:

"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”.)"

OK, but why? I think this is it (from same post):

"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."

But I don't really see why this is called "no estimates"? It's more like #EstimateScope. And I believe that it's associated with equal amount of problems as doing "regular" estimating.

I'd like to state one thing and then create a little scenario.

My statement

Working with real budgetary or constraints is really good. We do that in our business from time to time. But there are problems associated with it (I'll get to it soon) and very often business don't have a budget constraint, they have an idea or a problem they want to materialize or solve. They want to know how much to budget for that. Sometimes (quite often actually) customer have no real monetary benefit of solving this problem or idea (or it's very hard to calculate it). Then they still need to know the cost (roughly) so the board can prioritize among other things to do in the organization. "Shall we do this thing this year, or is it better to wait and try to see if we have more money next year, or shall we try to save money to next year to do this?". I see nothing wrong in this kind of discussions. And I can't "blame" my customers for not having a real monetary benefit of everything they do (even if they perhaps should, or should they really?).

Of course they have a sense already of the cost for things, and this is usually not communicated. I believe this is a "dysfunction" and that this sense should be communicated. Then we (as suppliers) will be more motivated what goals we're working at and knows the constraints behind this project. All great. But it doesn't really solve anything in the end (I'll get to this in my scenario later).

When it comes to "setting price/date for the kind of work you do regularly" I don't quite get this. I sense we're talking about portfolios or something similar? But isn't that super boring? The whole purpose of why I'm a software developer is to be able to solve problems or materialize ideas. I don't want to do "regular work". The beauty lies in creating great stuff and solve customers ideas/problems with solutions I haven't really built before. And if "work you do regularly" is about using the same frameworks, platforms and languages then this is how we set price already i.e. we estimate how much of this "regular work" is required.

A scenario

Lets create a little "play". Starring Me (M), Customer (C) and my CEO (O).

C: I have this idea!
M: Great! Let's look at it.
(Going through the idea in workshop like forms or similar)
C: So, do you think you can do this?
M: Yes, it seems like a great idea. And I can do it.
C: How much do you think it will cost?
M: Well, may I first ask what this is worth, what is your budget or can we create a budget?
C: Yes, I estimate we will have a profit from this at $100.000 per year for about five years time. So the benefit for us is roughly $500.000. But we need to have at least a break even in first year, so I'd like it to cost no more than $100.000. But we may decide do it anyway depending on what you come up with (estimate).
M: So the budget is $100.000?
C: Yes, but not necessarily. If you think it's more we may still decide to do it. But that depends, I can't tell right now, I will need to discuss that with the management team. If so.
M: Great! Thanks. I'll get back to you. Cheers!

(Me going to my CEO (O))

O: So, how did the meeting go?
M: Great! They want to build this thing and have a budget of $100.000 roughly.
O: Superb! Then we need to check if we can build it for that amount. Because if our cost for building it is close to that budget it's a great risk for both us and our customer.

Play over.

Whatever we do we still end up with estimates. We need to know with some degree of certainty (or margins) that our cost for building a thing isn't close to the budget our customer have. Otherwise we might soon be out of business.

And if we think we can build it for $20.000 or maybe $50.000. How do we know that without calling it an estimate? We haven't built this thing before. And *not* estimating and just return to the customer with the response: "Yes, we can build it for $100.000", is that professional? Customer will certainly ask: "But how much is it?" And they should be told what we think. Because it will make their decisions easier. If it's $20.000 we surely have a quick "Go!". And if it's close to $100.000 they might have to do some more thinking before we get a *quick* "Go!" (i.e. we slow down their process by not answering what we think - by estimating).

So, in this scenario #NoEstimates would actually be worse. It could even get us out of business; if we deliver stuff that costs us more than our customers pay us (budgets).

(This scenario is actually the business I'm in, this is what we do).

And what happens if we don't estimate and say: "Let's adjust scope so we can build *something* for that money (budget)"? Well, customer might end up with something they can't really use. What's the value in that? The common answer to this problem is: "We always work on and deliver the most valuable things first, thus they always have something they can use". I don't believe that. In my business (solving ideas and problems) the customer have a vision of what "done" is, and the idea ("done") usually doesn't deviate much when building it. The *details* of what will be built might deviate, but not the initial idea/problem. And not delivering that idea completely ("done"), but merely having "increments" of the idea ("done"), equates to unusable. That's my experience. E.g. how does increments of a "booking system" look like? "We can book, but have no UI"? "We can book, but have a crappy UI that no one wants to use"? "We can book with a beautiful UI but can't view the bookings made"? 

Of course, "done" doesn't mean we should build all little nifty details of everything in the first release. Plain agile thinking. Think of it as an MVP (Minimal Viable Product). But this MVP must be estimated. After that we can plan what will be included in next release (continuous improvements). But there is another thing that strikes me: knowing "size" of a feature is valuable for customer. There might be two (or more) "equal valuable features" and then an estimate of size will help decide which one of them we should include in the next release (prioritization). And even if features don't have equal value, customer might want to include those small sized features (estimated as such) anyway. It's their money, let them do that if they want to.

"Need for estimates"

No one "needs" estimates per se. Estimates without real need is nothing worth. But estimating is the tool we use for deciding things: *to choose between future paths*. We have had a need for that since mankind and we still need it in almost everything we do in our everyday life and business.
And no one really says "we need estimates". At least I've never heard it. And if someone do say that they're a victim of poor management (the basis of the decisions are not communicated). What can you do about that? That's the real question you should solve.

So, is this #NoEstimates tag just a misinterpretation? Is it equal to "Plans are nothing; planning is everything"?

"Estimates are nothing (NoEstimates); estimation is everything" #NoEstimates #YesEstimation