Estimates: Lies and Guesses?

Terry Bunio has already written a blog post on this Are #Estimates Lies? #NoEstimates. But I like to give my point of view on this topic as well.

To make a long story (blog post) short: "Estimates are not lies and guesses". There, you can stop reading here if you like :-)

Still here? I'm glad you would like to read more on my thoughts on this :-)

I hear that these statements are something that the #NoEstimates "community" claims to say or hold true. I haven't actually heard so much about it, but if it's true I would like (as a person thinking that the ideas behind #NoEstimates are good) to reject these statements - if so. But... there is a grain of "truth" in there... There is a reason why someone would call them "lies" or "guesses". Let me dwell on it.

Estimates are not lies or guesses - in the unicorn world! :-)

If you look at the pure definition of the word "estimate" (Merriam-Webster) you can see that it's not about guessing or lying. In the the definition you see words like "judge", "tentatively", "roughly", "approximate", "general".

But is this really the only usage of it, in the world of software development? Rhetoric. No.

And this is what #NoEstimates are trying to address. And this is where I think that #BetterEstimates and #NoEstimates share the same "interest". Maybe, in the end, we share the same solution to the problem: Communication! And in "communication" I put in words like "honesty", "transparency", "forthrightly" etc. Things that make communication meaningful and without "smell". Ok, maybe you should never be 100% honest etc? There might be situations. But you get it, nothing is ever 100% "true" or "false".

How does #NoEstimates fit?

In my opinion, I think it fits as a "topic" in this discussion about "dysfunctions" or "smell" associated with estimates. I see the hashtag as a "prefix" or an "abbreviation". I don't seem to get much throughput there, maybe I'm seeing things wrong? What do I know... But it's still my opinion, and I hold myself the right to change it later on, if someone points me at better :-)

But let me explain a bit.

Guesses

Sometimes I actually have no idea on how long time I think it's going to take when asked "How long..?" or "When..?". Usually it's because it's too vague or it feels too "big" to give a credible judgement - or anything else. 

The most honest thing is then to say that: "I have no idea" (or similar) (and when I do, we usually stop discussing estimates).  But when we're doing planning poker, or something else, it might not be easy to say that. Or when faced with some types of customers (you know which ones I'm talking about... :-) ). There's then a risk/chance that you do something that is more comparable with a "guess". Sometimes maybe the planning poker session is "forced" with: "We don't have time to discuss the details here, we must come up with a figure tomorrow" - i.e. "forced" to guess. 

Then I think #NoEstimates fits as #NoneOfThoseEstimates.

Sure, it's "bad management" or DDSTOP. But it fits the conversation, in my opinion. Like: "STOP!" or "NO!" (#No!Estimates?).

Lies

Sometimes, when I estimate, that estimation magically turns into a deadline. I.e. there is no "real" deadline (like market window, synchronization with other things etc), the estimate becomes the deadline. As in "We think we can pull this off in X sprints/iterations." and looking at the calendar that will occur at December 6. And the date is communicated up to the CEO (or whatever).

And in other times, estimates are "gamed". Like "Really that much!?" or "You have to cut that!". Usually in some "bidding" context. But I have actually heard customers say that directly faced with an estimate (and there are other reasons, than the estimates, why they say that).
And in other times, estimates are used because someone "above" needs a number to pass up the chain.
Etc...

In these scenarios you could actually call the estimates more like "lies" than "judgements".

Sure, again it's "bad management", "bad communication" or DDSTOP. But it fits the conversation. Again: #NoneOfThoseEstimates or #No!Estimates.

TL;DR

There are lots of other dysfunctions associated with estimates. All fits the #NoEstimates hashtag. Does it then mean: "Stop all estimations!"? Of course not.

And #NoEstimates also speaks of some "paradigm shift" on how both business and IT approaches software and how it is looked upon. But that's another topic :-)

But, #NoEstimates are centered round the fact that estimates are good if they are valid and used for the correct reason. No one thinks otherwise.

To fear #NoEstimates

There are two primary emotions. Some say. So do I :-). At least there are two emotions that all other emotions "derive" from. It's better that you read someone else's definition, and this one correlates well with my own definition. It is claimed to come from Elisabeth Kubler Ros (I haven't looked up the source, but it doesn't matter who has said what - I still like it):

"There are only two emotions: love and fear. All positive emotions come from love, all negative emotions from fear. From love flows happiness, contentment, peace, and joy. From fear comes anger, hate, anxiety and guilt. It's true that there are only two primary emotions, love and fear. But it's more accurate to say that there is only love or fear, for we cannot feel these two emotions together, at exactly the same time. They're opposites. If we're in fear, we are not in a place of love. When we're in a place of love, we cannot be in a place of fear."
Quote

So whenever you act, you act based on one of those two emotions. Fear or love.

When you're in the state of fear you attack. When you're in the state of love you embrace.

Behind fear is actually a call for help. Every person in fear is in some way asking for help. That thought can be helpful. That thought is comforting.

What does this have to do with #NoEstimates?
If you oppose #NoEstimates, ask yourself why you oppose it, based on those two emotions. You can actually ask yourself that question for anything, not just #NoEstimates. It's a really great exercise, but off topic in this post :-)

I have to admit that my #NoEstimates "journey" have been up and down. Initially I liked it, but then I started to dislike it (you can read all my previous blog post, if you want, to get a sense of that journey yourself). And now I'm back where I started :-)

So why did I oppose it ("back then")? Thus, why did I feel "fear"? This is basically what I thought:

Too broad definition

One of the reasons was that I started to see that estimates are a big part of what we do, every day. We estimate all the time, from big things to tiny little things. Heck, I even estimate when I write code (e.g. "How long will this piece of code take to complete, compared to if I write it like this instead?").
So, I started to oppose the whole #NoEstimates thing. I opposed it since it felt "silly". And feeling something is "silly" can easily be derived from the "fear" emotion. At least it's not an act out of "love".

Now I have chosen "love". In that emotion you don't see things as "silly". You instead ask yourself why you think it's "silly" (what do you fear)? Am I in a state of misunderstanding? Have I missed anything? Then I act on that emotion, instead of on my fear. I stop "attacking" and start "embracing".

Never estimate?

I also thought that it meant that you should aim at abolishing estimates, completely. This goes along with my previous point when it comes to the "fear" emotion.

When I choose "love" I see that I'm not seeing clearly, I'm missing something. Why do I act as seeing it as something "silly"? Does it really mean this?

Doesn't work for me

I also opposed it since I couldn't see how I could apply it in my own current profession. Maybe I still can't, but it's not the thing. I'm not going into details on what the "thing" is, it's not the topic. 

And no one really told me how I could apply it. Just "explore".

So, you could say I felt anger. And maybe jealousy? And I don't think I have to explain that anger and jealousy isn't derived from "love" at least? :-) When you're angry (or jealous) you easily "attack" (cause you're in a state of "fear").

When I choose "love" I can embrace that it works for others. Find inspiration and joy.

"Knowing cost..?"

How could you possibly tell someone the cost of something (if they want to know) without estimating? And isn't cost crucial when making decisions? Again, it's the "silly" thought. Or even the "Not doing this is really bad/stupid!" thought. That's attacking.

As I've already said, if I choose "love" I embrace that I haven't understood completely. You start asking embracing questions, not attacking ones.

"It's just bad management"

I felt that estimates are not the cause of the problem. And it isn't. I still believe that. The root cause is always people. Do I "fear" we're solving the wrong problem?

When I choose "love" I don't attack, instead I see that neither #BetterEstimates nor #NoEstimates will solve the "people problem". So either approach is ok, in that sense. Whatever might do the "people problem" at least better is worth trying. And #BetterEstimates have I already tried, and still are trying - so let's embrace another option. If I can. And embrace others who are trying.

Universal approach

Back then I was missing "actionables". I wanted to "do #NoEstimates". I thought it could be applied in any domain in any context anytime. And I was "frustrated" no one told me or showed me how to start. I was missing someone telling me when estimates where appropriate and when "no estimates" where appropriate.

Clearly a "cry" for help. An act when you're in "fear". You could also say I was feeling "frustrated" or maybe even "angry". Not feelings from "love".

But if I choose "love" I see that you shouldn't perhaps even seek #NoEstimates. It may be an outcome (from retrospectives). The only "seeking" you should do is trying to be inspired and realize "maybe I can't start, but what *can* I do?".

"But isn't it still a genuinely bad idea?"

This is more of a reflection I'm having now rather than something I believe I felt back then. So I'm going to see how you can approach this with "love".

Some developers/teams actually don't do estimates, and it's working for them. Why not be inspired instead? Encourage them, even if you can't possibly see how you could apply it. And if it turns out it actually *is* a genuinely "crappy" idea (even for those devs/teams), don't you think they would stop themselves (or be stopped)? Don't you think it actually won't be "universally" applied? But why don't you let someone else try, if they can and want to and it is for the better (for them)? As I said, be inspired instead. No one is forcing it on you. And if it turns out it actually is the universally-new-great-way-of-developing-software, don't you think it will be well tested in lots of domains and proven to be a better way first (like agile)? As I said, no one is forcing you to try or even telling you that you should try. Why not watch, listen, learn? Even if it "fails", it was worth trying it. There's a saying, I can't find it now (please help!) that goes something like this (out of my head): "It's better to take that step and fall than to be left standing on one foot the rest of your life".

And if you really think that trying to lessen the dependency on estimates in software development is a bad idea, why do you want to stop others from trying? What emotion is driving you? If they fail, even badly, they might still feel it was worth the try. You don't have to try. You even shouldn't. Maybe you fear (pun intended) it will drag a "bad name" around the whole software development "thing" - if others fail? I don't think you have to fear that. Really. If #NoEstimates is such a bad idea(?), I think I pretty much *know* what will be "blamed" as the cause for those "failures" (if so) ;-)

Conclusion

I think my feelings where: "that's silly!" or "frustration", "anger" and "jealousy". Those feelings are not based on "love".

So: let love drive you! :-)

"But aren't you allowed to criticize anything?"

Of course you are! I don't say - and no one is saying - that fear is something bad. Fear is as equally good as love - in the right situation. If you don't ever fear, you probably won't live a long life :-) 

And I claim that "criticism" can be derived out of either love or fear (as many other emotions).

But, just know (or try to see) what emotion is driving you in a specific situation. Are you acting out of love or out of fear? It might sometimes be hard to tell, but I think you know deep down. Are you attacking or embracing?

And even more important: is the person you are interacting with acting out of love or fear? If you look at another person, the one you're having "issues" with ("attacking" you), as someone who is "afraid", it might help you solve the situation better. Understanding the other person and why he/she acts the way he/she is acting right now. And remember, you can always *try* to let love drive you instead.

I don't propose a #NoFear hashtag. Even though you sometimes can choose love over fear, i.e. #NoFear (pun intended again) :-)

Estimates and promises

First, I'd like you to read this post by Joakim Holm about promises: "Promises, promises" Done? Fine, I hope you're now on track what a "good" promise is. In short (if you didn't read), if you *must* make a promise, then promise your own behavior. Only. If you start promise outcome you're taking a big risk. A risk of losing trust (among other things).

How does this correlate to estimates or "no estimates"? Well, in many cases estimates becomes just that: promises. It shouldn't, because is just an estimate, but can you avoid it? Have you ever given an estimate that didn't end up becoming a promise of outcome? Well, lucky you, if so :-)
Because when asked "How long do you think this will take?" simply honestly say what you think. It's as easy as that. It shouldn't be more complicated than that. It's an estimate, god dammit! (sorry about that rant...)
But, the problem arises if you give them a number (or a range, for that matter). Because it's very easy for that number/range to become: a promise. And more specific: a promise of outcome. And the problem becomes even larger if that number starts to travel up to the organization. It becomes a "promise chain", and you're, unfortunately, at the bottom. This is nothing strange really, it's human behavior.

So, what can you do? Easy. Don't give a number/range.

Wait a minute... Will that actually work in business?

No. I'm sorry that won't work. People need that number. So you have to give that number. And you will (one day or another) get in to trouble. It's as simple as that. Well, to be honest, if you get in to trouble it wasn't because of the estimate, something else is wrong or dysfunctional (and that's my version of #NoEstimates, as in: "It's never the estimates fault", but people don't seem to buy that :-)

So, to get around the problem you can try to pad that number and talk about margins, probabilistics and all kinds of stuff. But I'm sorry, it makes no difference. It will still be a promise of an outcome. And since you can't possibly *know* the outcome, it's always a risk.

Sure, if you're very very confident (like 99.99%, can you ever be 100%?) you will make that number, give that promise. But how often are you in a situation where you can be that confident for software you're going to write? If you think of it, you're always too optimistic and, at best, give maybe 50/50 chance. Read more here "My estimates are too optimistic" And if you would start to give higher confident estimates (to give a "promise of outcome" I'd say you need to go up to over 99.99%) your customer will probably say "That's way too much money". And then all you did was to help them abandon the project. Or you resort to promise an outcome with lower confidence = RISKY!

And I would even claim that if you (with customer) don't come up with other ways of solving the problem or that you (with customer) learn something - along the way, as you *do* stuff - that will make the solution even better than what you initially thought, it's probably a failed solution. At least it's a mediocre solution if that happens. So, the only thing you *know* is that things will change - if you (with customer) wants to build better. This is basically why most companies abandon waterfall and go for agile; you can't know in advance what you want, so it's better to iteratively work the requirements as you go. But how can you ever promise an outcome if you *know* it will change? Easy, you can't promise that.

What to do?

I'm sorry, there's probably nothing you can do. Give numbers and get in trouble :-)

Actually there are ways of working that minimizes or even eliminates the need for someone to ask for numbers. But that is out of scope of this article.

Still...

If it's possible there's something you *can* do. I'm not saying it is possible in your scenario/situation, it's up to you to decide.
But you can decide how you want to lead your life. It's up to you. If you give promises of outcome it may affect you or others negatively. Working long hard hours, neglecting family and friends to meet that promise you gave. It creates pressure and stress that will lessen quality of what you build and will increase the technical debt. And more. All in all, promises are powerful stuff. It affects you heavily. But you can choose how to live.
You can choose to say no. If it makes your life better. It's up to you. And good people will probably appreciate someone who says no.
What do I mean by saying "no" in this case?
If you are going to estimate cost/time. Require that the person asking gives *you* an estimate first. An estimate of benefit or a budget and when it has to be done. You can call it "real constraints". And then all you (together) have to do is to see if what you think (yes, an estimate) is close to what they think (yes, an estimate). If it is close, then there's a risk. Simply discuss this risk then. Solve it together. Probably you (as in: you and your customer) will end up cutting scope to a point where you feel comfortable you *can* promise an outcome (that 99.99%). And if everything works smoothly (how often does that happen?) there might be time left to add small improvements one by one (this is close to the approach I talked about earlier, on how to not getting a request to give a promise of outcome at all). Hence, this scope cutting can result in a half MVP (Minimum Viable Product): a PYNPO (Product You're Not Proud Of), or even a half PYNPO: the PYMTGO (Product You Managed To Get Out). :-) Then work from there.
Or maybe not. Maybe you are comfortable to say something like: "I see no problem to get this done for that price and/or that time." Sure, that's a promise. But if you know you *will* make it (fulfill promise of outcome), unless you get run over by a truck or get your hands cut of: make that promise! But how often are you that certain of your promises of outcome in software development? Given you cannot know in advance what you will learn and improve and adapt to as you go along.
Or you (as in customer in this case) can agree to "live with the risk". Simply "Let's do our best. If it succeeds, it does. At least we have tried and has gotten something." I've actually worked like that in many cases, when something started a bit (or way?) too late and cutting scope is not applicable. If you're honest, customer is usually fine with that, they know they started late and can't require you to do miracles just because of that.

Bottom line, avoid signing contracts that acts as promises of outcome. It can be done. And remember "Customer collaboration over contract negotiation" is being agile.

I've also written another blog post on almost the same topic: "What #NoEstimates has taught me"

Risk sharing

I've mentioned risks. And in this case it's about "risk sharing". You both take a risk when getting into a project with only "I think this can be done within this time/budget, but I can't promise it". If you think of it, risk sharing (in itself) is actually fine. Because it is a promise of behavior: "I promise to ___ if ___ happens". That is all fine. It's an easy promise to keep, if you know you will do ___ if ___ happens, that is :-)

So, how do you come up the figures of what ___ is? That is up to you. But do you have to put up figures there..? Think about it.

My answers to "Consolidating the #Estimates/#NoEstimates Debate"

Background

This post is my answers to Shim Maroms questions in his great blog post, which you can read here: http://quantmleap.com/blog/2014/02/consolidating-the-estimatesnoestimates-debate/

I'm a bit late on the response, but I hope you can forgive me. I've been back and forth with this #NoEstimates "thing". At first really into it. But then really disliking it (for various reasons, you can read me other blog posts and get a sense of that yourself). Mainly, I think it was because there where no "general guidelines" or "actionable items" on how to "do it", and that frustrated me. And I'm that kind of person; I like (want) guidelines or books to read, or whatever, to get me started. I can't really think for my self, and that is needed if you're after #NoEstimates ;-)

I also took the "extreme" stance that estimates are always present when making decisions. And I was right, they are always present when making decisions, but then we have to take the broad definition of the term and that is not what #NoEstimates is about. It doesn't mean developer estimates, or the typical formal (usually dysfunctional) delivery of them is always required. That is, the way we usually use estimates in software development today is actually pretty dysfunctional (you all know what I mean). We need none of those, i.e. #NoEstimates.

But now, I have taken the right to define my own version of #NoEstimates. I don't think anyone owns the hashtag, so I guess I'm entitled to define it how I like. You may not like my definition, and you're entitled to not do so as well :-)
But it goes something like this:

"If you have any problem or dysfunction with estimates, it's not the estimates you have a problem/dysfunction with. I.e. a #NoEstimates problem/dysfunction."

What do I mean by that? Well, it means you don't have to try to "improve" your "estimation techniques" or anything like that. Improve other things, like customer collaboration or  how to have an open communication or improve honesty, trust, transparency (or anything typically "agile"). And never "blaim" the estimates if project is late or over budget. It isn't the estimates. Don't even discuss estimates, i.e. a #NoEstimates discussion. It's other things (like dysfunctional management, lack of trust, missing a clear vision, misunderstanding in requirements and/or expectations, no risk handling, bad communication etc etc etc). You can call this root cause analysis, and they will probably never lead you to estimates. They are just that: estimates. If they turns out to be incorrect, something probably happened along the way. They where right, for you, when you did them. And estimates are not meant to be accurate, they are by definition rough (read Merriam-Webster's definition, if you don't believe me). Thus, they are never right (or you're just lucky).

I've also realized (through discussions) that some developers actually writes code without estimates. And it's working for them and the company they work for. I can't deny they exists :-)

But - and this is important - it's not universally applicable and there are no guidelines. Actually, you should not even seek for "no estimates". It might just, sometimes, be a natural outcome of something else. #NoEstimates means you should not let estimates drive you anywhere, not even towards "no estimates" (funny enough).

The reason people are seeking #NoEstimates is because they relate some kind of dysfunction with estimates. We all have that in common. Both proponents and opponents. I see no reason to "start doing 'no estimates'" just for the sake of it.

Long rant about that :-) But it's important for me to let you know this and get you into context before you read my answers. Here they are:

Answers

"Are cost estimates required in order to manage software projects?"

No. But they are usually (almost always) required if someone wants to know cost before deciding to start the project at all. Sometimes getting something out quickly is more important than estimating the cost first. And some companies actually don't let "developer estimates" drive their business, not even for cost. How? Ask them :-) But this is, again, all about context and specific situations. I sometimes write code without estimating the cost first, as well.

"Are cost estimates an effective tool for controlling costs?"

In those situations where they are needed, yes. And those situations are very common :-) In the broad definition I guess cost cannot be anything else than an estimate (when writing software that is). But are "developer cost estimates" an effective tool? Yes, that too. If we remove all dysfunctions that goes along with them (if that is possible), as I've said.

"Do estimates stifle creativity and kill innovation?"

No. But if they are considered as promises (again, another dysfunction) they might create pressure on developers which, in turn, stifle creativity and kill innovation. But not the estimates themselves.

"Do people need estimates? And if so, why?"

Yes. In the broad definition it's what we do all the time. We won't survive without estimate. They've been around since mankind. Even animals estimate. Do people need developer estimates? No. No one really needs those (in that sense). But to know cost of something you must estimate that cost. If we could tell you cost without developer estimates, we would probably do it, thus we don't really need them per se. But, so far, I think there is no other way but to estimate (although some claim they can).
But, my point, if we would remove all associated dysfunctions with estimates, they are a great tool, thus we need them. For knowing cost of something.

"Is the very act of estimation results in the creation of uncertainty?"

Yes. But up to a point it might be silly to try to estimate something. If it's completely unknown how long something might take (that happens) start with a PoC and budget it. What is produced in the PoC can usually be used in production code. Thus, it adds real value and makes further estimation easier. PoC is usually a "no estimates" approach, IMO (in the sense that it's not driven by estimates). Maybe you can do an entire project with PoCs? I don't know

"Is estimation a practice still hanging over from the Waterfall era?"

No. XP and Scrum (considered agile, I'd say) explains how to estimate (story points etc). But most agile principles actually are a step towards less dysfunctional estimates, by highlighting alternative ways to estimate.

"Is No Estimation better than Bad Estimation?"

Strange question. What is a "bad estimate"? You probably don't know that until afterwards. And then, as I've said above, it wasn't the estimate that was bad. If "bad" means: "I'm intentionally making a bad one" I'd say yes. But that's just hypothetical.

"Is Estimation really just a form of Guessing?"

No. If it is, ask yourself why you are guessing. Surely something else (not related to estimates) is wrong.

"Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?"

No. As I've said, if pacifying is needed you have a "no estimates" problem (that is, a problem not rooted in estimates).

"Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren’t estimates a tool used to apportion blame afterwards anyway?"

First question: yes (as I've said, it's not the estimates "fault", it's other things that fail).
Next question: it might be. But, again, you don't have an estimates problem then.

"Is costing a necessary tool for determining business value?"

Yes. But it's very common that the value (or mainly benefit) part is forgotten by customer. They focus merely on cost instead. Or the "value part" is missed to communicate down to the dev team. This is what #NoEstimates is trying to address as well. But the problem is not related to estimates, it's about lack of communication and/or lack of focus on benefits as well as cost.

"Does the scope drive the budget or does the budget drive the cost?"

Depends. Can't easily be answered without context. It's still quite common that the scope drives the budget when it actually doesn't have to. Basing the budget on some optimistic estimates with no margins can be "lethal". It's also quite common that customers don't want to tell their budget. Afraid we might "burn it all", just because we can. Perhaps. But has nothing to do with estimates. It's about low trust and poor communication and/or honesty and collaboration.

"If estimates are required in order to support decisions, can decisions be made without estimates?"

In the broad definition, no. A decision is, by definition, "choosing between future paths". And the cost of choosing one path over another is crucial for decision. Always.
But if we talk about e.g. "formal delivery of an estimate", decisions can be made without those, yes. And decisions can also be made without "developer estimates". For instance if something is really important to get done quickly - and that is more important than knowing the cost before starting.
But the "cost" of all those decisions are in the end: estimates.