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

Answers to Woody's questions

Woody Zuill is suggesting that we should ask ourselves - and answer ourselves - a couple of questions regarding estimates. The questions are available here: http://zuill.us/WoodyZuill/2013/04/25/agile2013-lightning-talk-noestimates/

I probably have misinterpreted how the questions should be used, but here it goes anyway.

Here are my answers:

• What are estimates, anyways?

"a: to judge tentatively or approximately the value, worth, or significance of
b: to determine roughly the size, extent, or nature of
c: to produce a statement of the approximate cost of"

Source: http://www.merriam-webster.com/dictionary/estimates
In software, it's usually perceived as the act of guessing how "big" something is. Usually disconnected from the business needs (those buying the code we write), but I'll get there.

• Are estimates useless? wasteful? harmful?

They might be perceived as those things. Usually because they are disconnected from the business needs (those buying the software). We need to collaborate and communicate better. If you produce estimates down a "promise chain", and you're at the bottom, of course that's what you'll feel. But does that make estimates wasteful and harmful? No. The use of them might be. But can be avoided with better communication and collaboration (internal and external).

If they are percieved as the things above (i.e. as a "weapon" and not a tool), you are probably a victim of "dysfunctional management". Don't "blame" estimates for that. And, starting with (or even trying) "no estimates" will certainly not stop this "dysfunctional management". It might even make it worse.

A "thing" cannot be harmful, only human behavior.

• Who needs them? Who is asking for them?

In the end, or directly, those who is going to pay for the code you write. They want to know, roughly, how much and when to expect what they pay for. Usually that is missed down the chain.

• Why do we think we need them?

Who are "we"? Developers? We don't really need them. But they might be a great additional tool when e.g. discussing the complexity of something, read more here: http://eirabrunstad.blogspot.com/2014/01/no-estimates-hype-or-not.html

I like to have more options, not less, so removing estimates ("no estimates") as a tool seems unpragmatic, in my opinion.

• Can we have successful projects without estimates?

Not sure. Depends on domain and context. And what is "successful"? To me it's about delivering something my customers are happy with and hopefully provides expected value to them. But if we deliver late and over budget, they are of course not going to be happy. But customer must feel that the "cost" put in to it is less than the value it provides. Both must be estimated beforehand, otherwise business (those buying our software) can't evaluate if it's worth starting the project at all.

• When will this be done? How much will it cost?

Estimate it. Those buying the software wants to know. Of course they want to know. It's their right to know, it's their money.

If you can give a sense of cost and time without estimates, please let me know.

I've often heard: "Fix budget. Define cost and let scope flex." But if I was a buyer of software, that's not how I would prefer it. Not always at least. And how will that solve any problems? How do we avoid customer adding lots of scope? The cost is defined - let's add! Or, how do customer knows what they have in mind will be done in time and available for the cost defined?

The "problem" will just be pushed to another place, "same sh*t, different name".

• How can we decide if we should do a project without knowing the cost?

Flip coins? :-) Jokes aside, there might be occasions for this, but they are probably rare. I don't even know any.

I wouldn't want to do anything without knowing the cost of it. I'm a DIY. I always "require" estimates from myself. Why? To know the cost and value for different solutions. Why? To determine which way to go. I.e. which project to start now, and how to do it.

I don't think software is any different. I write code as well, and writing code is just as uncertain as remodeling my old house :-) But a rough sense of cost and "benefit" I certainly want before tearing down a wall. To not mention my wife :-)

I don't think my customers reasons any different.

• Is NoEstimates better than MoEstimates?

Less is more :-) Not having any estimates at all (no estimates) seems worse than swimming in them. At least as a buyer. But if I (as a buyer) is going to pay for the estimates, I'd like to have "enough". Enough so you, as a provider, feels comfortable with them. Up to a level where I will not be certain you know what you are doing at all :-)

• How expensive are useful estimates?

Very context depending. In my domain, they are not very expensive. We could (and should) improve how we deliver them and communicate them and collaborate them. But expensive? Not very, in my opinion.

• How useful are inexpensive estimates?

Ours are pretty inexpensive, and useful for our customers. Useful enough so they can decide.

Consider "blink estimates": http://dannorth.net/2013/08/08/blink-estimation/

"Gut feeling" (instant) estimates are actually very useful.

• If it takes you “no time” to do estimates, are they of any value?

"No time" I interpret as "blink", thus see previous answer. They are valuable. Wouldn't write a contract based on them, but valuable? Yes.
Some say "gut feeling" or intuitive estimates are not estimates in that sense. I might agree on that, at least I know what they mean. But, even if we do "implicit" estimates, why not make them explicit? What's wrong with that?

• If estimates are waste, would you still do them?

No. Of course not. But are they? Really?

• Is the reason you do estimates because “someone requires I do estimates”?

No. Customers wants to know what they are expected to pay and when to expect it to be finished.

I can still see how some organizations fail to communicate the need for them. But fix that. Don't start (or try) "no estimates" first of all. Communication and collaboration will get you to a point where you see the real need and use of estimates, why we provide them and what they are used for by those really wanting them.

• Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?

No. But I can see how this can be in some organizations. But I've covered this. You won't fix "dysfunctional communication and collaboration" by starting with (or trying) "no estimates". Fix the other things first.

• When someone asks for an estimate, what do you do?

I make sure they are connected to real need (time and/or money or prioritization of items based on effort vs value). In my domain they usually are. 

A good approach would be to ask what the estimates are going to be used for and who is the real receiver of them.

• When estimates don’t work well for us, should we just get “better at doing estimates”?

No. Do a root cause analysis of why estimates isn't working for you. I bet you will see the root cause as "bad communication (internal and external) and collaboration (internal and external)". 

• If estimates are useful and easy to do, why do we still have so many problems with estimates?

They are not easy to do. Is programming easy? If we are skilled enough to write software, we should be skilled enough to estimate the effort to write it as well.

Why do we have problems with them? Again: "bad communication and collaboration".

• How would you plan a project if you were NOT allowed to do estimates?

The same way as I do today. Define what "done" looks like (in collaboration with customer). And in which order things needs to be done, and prioritize valuable and/or "risky" tasks first. And discuss project risks overall

If you ask how to schedule a project and connect resources without estimates, I have no idea.

• Can you imagine any reason why estimates might be harmful?

No. Only the use of them. A "thing" cannot be harmful, only behavior can be. Considering doing away with estimates (no estimates) won't fix the reasons for harmful behaviors.
Remember the "statement": "Guns don't kill people, people kill people". That statement is actually true, but contains a big error. See it? Well, guns are designed to kill. There is no real usage of guns except killing (well there are some sports made up around gun shooting, but that's basically playing: "who's the best at killing most efficiently"). That's not the thing with estimates. Estimates aren't designed to be harmful. They have been around since mankind (heck, even animals estimate). But are they harmful by nature? No.

• Can you imagine some better way?

No. There might be alternative ways. But better? Don't think so.

• How important are predictions?

Very.

• Can you “sell” programming without estimates?

No, not in my domain at least. More important question: is buyer willing to pay for programming without having a sense of how much? It's not the "seller" who gets to dictate the rules. It's not his/hers money. "Customer is always right".

If we can "sell" programming without making estimates I would be happy to know how that can be done.

• What about estimating the “value” of a feature?

Yes, that needs to be done as well. Business (or "buyers") do that already (hopefully). Anyway, it's not your money. But let's try to keep communication and collaboration open. That goes for everyone.

• Are there things where estimates make sense?

Yes. Lots. I've written about some already: http://kodkreator.blogspot.se/2014/04/useful-estimates.html

• What is “No Estimates” anyway?

Exactly, good question. I don't really know. Usually it's interpreted as "refuse to estimate" and/or "estimates are always waste". But I think it's not. Don't really know how to approach it though...

• If estimates are good for some things, does that mean they are good for everything?

No, of course not. But estimates are very often present in everything we do in life. "How much shall I eat? When? Will I make it to the meeting in time? Can I afford this? Is it worth it? Can I cross the street before that car gets here? Will this thing fit here? Will this code be more readable than that? Will it be more maintainable? Will it have good enough performance?" etc etc. 

We haven't found a better way to "create letters on some media" to communicate and/or document some text. Should we seek ways to stop that and try better ways? Maybe, not sure it's sane though. I believe estimates are the same. We have even been doing estimates longer than we've been creating letters on some media. Why should they go away now?

• Does “No Estimates” mean we don’t use estimates at all?

No. But where do we use it and where should we not use it? How should I, as a developer, approach it?

• What are “Whole Team Estimates” and does it help at all?

The team sits and estimate together. Collaboration is great. So yes, it helps. Better up would be "Customer collaboration estimates", i.e. estimate in collaboration with customer. Not sure how that can be done though.

• If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?

No. If you don't understand enough, collaborate with customer: "How do we progress?" Everything will be great if we start communicate and collaborate.

The team/developer building the thing should get a chance to estimate it again. Or the team/developer estimating should be the one(s) building it. Important "rule". Poor management if that doesn't happen.

• How much are you willing to invest in estimates to get useful information from them?

That depends. Talk to customer. Collaborate and communicate. It's their money. "Spikes" and "Proof of Concepts" are some tools to gain knowledge for better understanding or build prototypes or mockups. But those needs to be estimated as well, "How much should we budget for a PoC?". But that's approaches to be able to produce more accurate estimates.

• Does it matter how good estimates are: are “wild guesses” good enough?

Why make "wild guess"? If uncertain, talk to costumer. Collaborate.

• Are the decisions you are making that are based on estimates good decisions?

Yes. Depends on how the estimates are delivered, under which circumstances and by whom.

Response to "Can we put an end to this ‘Estimate’ game of fools?"

This is a response to the blog post: http://blog.frankel.ch/can-we-put-an-end-to-this-estimate-game-of-fools
I think writing a blog myself is the best way to share my alternate opinion on the matter. (The original blog post is quoted in this post for easier reading).

When I was a young software programmer, I had to develop features with estimates given by more senior programmers. If more time was required for the task, I had to explain the reasons – and I’d better be convincing about that. After some years, I became the one who had to provide feature estimates, but this did no mean it was easier: if the development team took more time to develop, I had to justify it to my management. Now, after even more years, I have to provide estimates for entire projects, not just fine-grained features.

This is a management dysfunction. The ones estimating must be the ones developing the thing estimated. Or add margins in the estimates for "junior" (or inexperienced, we all are from time to time) developers. Never blame developers for "wrong" estimates. It's how poor managers use them. That's what's wrong, not the estimates.

But in essence, what do we need estimates for? For big enough companies, those are required by internal processes. Whatever the process, it goes somewhat along these lines: in order to start a project, one needs estimate in order to request a budget, then approved (or not) by management.

We need them for making business decisions. I'll come to this later. But, just as you say: business needs to budget investments (projects) and prioritize them with other (even non software) projects.

Guess what? It doesn't work, it never did and I’m pretty sure it never will.

Why does some companies do this well then? Maybe look at how they are doing it?
The business needs budgets. If you've ever been a member of the board at any organization or cooperative, you know the importance if this. Very often the board needs to know what to budget for something that needs to be invested, and how can they do that without asking us for estimates? Even if they know the value of an investment they need to know the cost as well, it's called ROI (Return Of Investment).
One thing we usually miss is to add margins when needed (for uncertain items). Read this post: http://www.leadingagile.com/2014/02/use-agile-build-next-home/
I always add margins when I invite guests for dinner or when I go traveling or remodel my house. Do the same with software development.

Maybe we can keep price fixed and estimate the scope. Not as good in my opinion. Why not build the best thing? Maybe your customers are happy adding budget (or use margins) for some things (added scope). It's all about customer collaboration. Tell them where they should add margins/buffers.
If estimates are still "wrong", in the end? Well, "execute your risk plan" for this (which you discussed with the customer/stakeholders before project started: "What if the estimates are wrong?"). Don't have any "risk plan", fix one next time, but for now remember: Customer collaboration.

Note: some organizations are smart enough to realize this and couple estimates with a confidence factor. Too bad this factor has no place in an Excel sheets and that it is lost at some point during data aggregation

Exactly. But, why do you think it has no place in the excel? And why is it lost? Fix.

Unfortunately, my experience is the following: estimates are nearly always undervalued! Most of the time, this has the following consequences, (that might not be exclusive):

Yes, stop lying to yourself. Optimism is a disease when estimating.

In general, the first option is to cancel all planned vacations of team members. The second step is to make members work longer hours, soon followed by cutting on week-ends so they work 6/7. While effective in the very short-term, it brings down the team productivity very soon afterwards. People need rest and spirit – and developers are people too!After pressure on the development team, it’s time to negotiate. In this phase, project management goes to the customer and try to strike a deal to remove parts of the project scope (if it was ever defined…). However, even if the scope is reduced, it generally is not enough to finish on budget and on time.The final and last step is the most painful: go back to the powers that be, and ask for more budget. It is painful for the management, because it’s acknowledging failure. At this point, forget the initial schedule.Meanwhile and afterwards, management will communicate everything is fine and goes according to the plan. Human nature…

 Management dysfunctions. Tell how you feel. Don't accept working overtime because someone is using estimates as promises. Fix the dysfunctions. Customer collaboration. Quit, at worst.

In some cases (e.g. a bid), that’s even worse, as the project manager will frequently (always?) complain that those estimates are too high and pressuring you to get lower ones, despite the fact that lowering estimates never lowers workload.

Same thing as my previous response. What's the purpose of using estimates as pressure? They are used for making decisions and understanding. Don't be optimistic. Don't accept pressuring. Ask what the estimates are going to be used for. Seems like they are used for something else here. If things don't get better, quit at worst.

You could question why estimates are always wrong. Well, this is not the point of this post but my favorite answer is that Civil Engineering is around 5,000 years old and civil engineers also rarely get their estimates right. Our profession is barely 50 years old and technology and methodologies keep changing all the time.

Estimates are never right. It's in the nature of estimates. It's *estimates*. But my estimates are almost always close, at least close enough. And if things change so much that the initial estimate is off, tell customers or stakeholders. Remember *Customer collaboration*.

I’m not a methodologist, not a Project Manager, not a Scrum Master… only a Software Architect. I don’t know if Agile will save the world; however, I witnessed first-hand every upfront estimate attempt as a failure. I can only play this game of fools for so long, because we’re all doomed to loose by participating in it.

Don't play games. Be professional. That goes for everyone in the organization.

Useful estimates

When someone asks me to produce some kind of documentation, I always respond with asking back "What is it for, and who will use it and for what purpose? Documentation quickly becomes outdated and needs continuous updating. We need to know all this before providing it."

We should respond the same thing when asked for estimates (just replace "documentation" with "estimates" and you're good to go).

Unfortunately I think the #NoEstimates "movement" tends to "drag down estimates in the dirt". I feel I need to lend it my hand...

We need to recognize that estimates have a lot of value. Sometimes it's actually not even a good option to try do away with them.

Here are some:

NB! When I say "you" below, I mean "the team" including product owner (of course) in collaboration with "customer" (or whoever is paying for the software you produce).

Prio

When there are items in the "backlog" (or other "idea list" you have) that have roughly the same value (actual or perceived), estimates provides great knowledge. Maybe you want to pick the "easiest" items or maybe you want to do the opposite and tackle the "hardest" items. I'm not talking about risk or value here, they are roughly the same (but still, estimates may provide great knowledge even for those).

Worth doing

Sometimes some items or projects doesn't have a clear "payback". They actually exists. Or maybe the "payback" is quite difficult to measure. But it's still an item or project the business wants to do (anyway, it's not your money). Then an estimate provides great knowledge to decide if it's worth doing. If it's too "expensive", maybe it's not worth doing it at all, not even a small increment/PoC/MVP/walking skeleton or anything.

Or maybe it is? Then we still need to define how much to spend on it and estimate if we can produce anything useful or gain enough knowledge for it.

If we can't measure the "payback", how can we know it's "too expensive"? I don't think it matters, it might just be a gut feeling or a wild guess (just like our estimates..?). But remember, it's not your money.

Worth doing #2

This is the most obvious, in my opinion. This is when you "know" what the investment is worth. You know what the goal is and how to measure the "success".

Maybe you want to start building on the most valuable or "risky" part first. Or build a MVP (Minimal Viable Product) or any other incremental approach. Or maybe you must have it all (that actually happens).

But, whenever you want to spend your money on something, you want to have a sense of how much (and sometimes when to expect it). I think you have the right to get that sense.

As a customer (the one buying your software), maybe I can define the cost upfront? Sure. But it's quite often not how I want to spend my money. "I want it all and I want it know!" :-) Seriously, I usually know what I'm after, I just want to know how much that is.

I might already have a sense of how much it is. Let's then see if we share that view. But maybe I haven't got a clue? I must then have the right to know if it's worth doing.

Anyway, I have a right to know how much this thing is, that I want. Even if I probably (in the end) don't want exactly that thing I thought I wanted. But please, tell me anyway. Tell me that it might be more expensive, or cheaper. Tell me I probably don't want what I think. Tell me what risks you see and other "unknowns" that might be expensive. Tell me how you want to solve that. Where should I put margins.

But let me know how much I should "budget". Let's solve it together.

Whenever I invite people for dinner I have margins. I over-estimate. I want to know it's enough for everyone. Even if it was "waste" in the end. I can eat "the waste" myself later. If my budget is low, I probably cut down on the number of guests, or buy something cheaper to eat. But let's all be honest with this. Be transparent. And my local supermarket will gladly help me with this. They will surely ask how many guests I've invited and what "quality level" I'm aiming for. But they will surely estimate the amount of food I should buy, and I will say I want to have margins.

Can we do the same?

Shared understanding

Sometimes estimates are great to determine if you have the same sense of the "complexity". Or if you share the same view of "done" and how to get there.

This is true both inside and outside the team. Maybe your customer have a budget already, or they might have a sense of the cost already. Let's see if we share it or if it's doable?

If your customer have no budget or no clue at all, estimates provide little or no value when it comes to "shared understanding". Just saying.

Are there other cases where estimates provides great value? Please let me know, and I'll happily consider updating this list.

For the #NoEstimates discussion to be viable we need to consider when estimates actually are valuable.