Yesterday, I tweet-improvised a thread that’s included below. I had intended to write it up later as an article on my site, and here it is. It received a number of replies and comments, and I’ll address some of those here as well. First, some warmup:

TL; DR

Summing up, or in a nutshell, …

Estimates are always waste; they are not our product. We wish to reduce this waste, as with all waste. Therefore we should always wish to reduce estimates. In the limit, this activity would result in “no estimates”, the famous hashtag.

Of course, there are complications …

Twitter Thread on Estimates

So I was thinking about #noestimates. I’d think we could agree that IF estimates were not needed, we would not use them, because waste. (If not I have something interesting to learn.) And WHEN they’re not needed, we’d not use them, I should think?
/1

Now I want to suggest that estimates are always waste. They are not product (I hope) so they are automatically waste. We should want to get rid of them on those grounds.
(See Waste)
/2

Now I am somewhat bemused by people actually arguing FOR estimates, rather than saying “well, they are waste, but unfortunately they are often necessary, so we should be good at them”. Maybe someone will explain that to me. But that’s not my point.
/3

Since they are waste, if they are not necessary, surely we all would like to get rid of them, save only the people whose job it is to produce estimates. Their hands are not clean and we’ll ignore them.

Now I want to tell you a story.
/4

On C3, we estimated all stories in days. (After a while, I think we went to points. If we did, I’m sorry now.) And we kept track of how many days / points we got done in an iteration, and next time we planned, we’d add up the points on the desired stories.
/5

We’d sign up for /about/ that many. Sometimes less, if we felt the stories were actually harder than when we estimated, or if someone with special knowledge was away, or if there were all hands meetings, or whatever.
/6

We (usually) had a pretty healthy situation, and so it (usually) went pretty well. If we were a little optimistic, the Yesterday’s Weather would adjust it, and if we could identify why we fell short, we’d improve something. It was all pretty good.
/7

Estimation was working pretty well for us, most of the time. The estimates usually didn’t go out of the room: we just used them for our own selection of work. It seemed like the thing to do, because we had been taught to do it.
/8

We also had acceptance tests for every story. Every single one.

Had we known the trick, we could have broken our stories down into single acceptance tests, and streamed them in. That would have reduced the variability in story size very substantially.
/9

Variability was already quite low, because we never undertook anything with a very large estimate: we’d split it or spike it. But had we gone to single acceptance test, the variability would have been even smaller, and we could have always just signed up for, say, 10 stories.
/10

We could have eliminated those estimates entirely. Now the purists will say “but you were still estimating” and yeah sit the fuck down. The point is we could remove this active estimation with some mechanical process that looks like counting, not estimating.
/11

It would have reduced waste, reduced time spent estimating, reduced time spent doing arithmetic, reduced time thinking about variability that wasn’t needed. Had we thought of it, it would have been a good thing to have done.
/12

Since estimates are always overhead, always waste, every such elimination, if it can be done readily, at lower cost than the original estimation, it SHOULD be done, because we should always reduce waste.
/13

What is the limit of this activity? We should keep eliminating waste, including waste from estimates until there is none. The limit is:

NO ESTIMATES.

That’s why it’s a good idea and why it’s probably a good hashtag as well.
/end

Next Day: Tweets on Waste

Today, based on feedback from the Twitterverse, I tweeted this screed about waste. I think it’d be best if you read it next, before we dig in further.

Apparently we need a little digression on waste. I’ll leave it to you to study the 8 kinds of waste that lean addresses, and the Toyota notions of muda, muri, and mura. Maybe some links, below, if I remember.

I think about it a bit more intuitively than that.
/1

Presumably we’re “in the business” of building something. Building a software product is at the top of my mind, but we could be writing a book or having a bake sale. The “something” is the software, the book, or the cookies.
/2

Everything we do to produce that product is an “expense”. It goes on the expense side of the ledger, if I understand how ledgers work, which is open to question. The money we get from our cookies goes on the revenue side.
/3

Roughly speaking, revenue good, expenses bad. We always want to reduce expenses, and we always want to increase revenue. Sometimes the two go hand in hand, sometimes not.
/4

If we sell the book on e.g. Leanpub, we can reduce our expenses in building it, and (possibly) increase revenue from getting a higher percentage. Expense reduction and revenue go together. Super.
/5

If we don’t have a copy editor for our book, it may be full of typos and people will say it sucks and no one will buy it. We increase expenses by getting a copy editor, and increase revenue. Reduction of expenses and increase of revenue do not go together.
/6

But as soon as we have the copy editor, we have to accept in our minds that this expense is “bad”. This money is “wasted”. In principle it need not have been spent, if we’d only learn to spell and stuff.
/7

Everything on the expense side is waste. Some of it is necessary, some of it isn’t. We often think that some expense is necessary when in fact it is not.

That’s the point of the preceding screed on estimates: we often think they’re necessary when they’re not.
/8

In principle, we always “want” to reduce expenses to zero. Sometimes we can. Sometimes it’s easy. Sometimes it’s hard. Sometimes the effort to reduce the expense pays off. Sometimes it doesn’t.
/9

But it is /always/ legitimate to try to reduce any expense. It may, however, not be productive. That’s a different topic.

In principle, we would like to reduce all expenses to zero.
/10

In principle, we would like to simplify all estimates, make them easier to get, easier to use. In principle, we would like to eliminate them entirely, if we reasonably can.
/11

The point of the preceding screed is not that we can get rid of all estimates. It is that getting rid of all estimates is not a crazy thing to want. They are expense. They are waste.

So, if you’ll think about it, maybe you’ll see that there’s a different, better question:
/12

“Given these estimates right here, and given that we know that they have impact on the expense side of the ledger, is there a way to avoid doing the estimates, with a acceptable impact on the revenue side of the ledger?”
/13

That’s always a sensible question. Sometimes, the answer is “No, they’re easy enough to get and doing no harm, let it be.” Sometimes, it’s “Yes, kill these estimates.” Sometimes, it’s “Let’s explore a bit and then decide.”

ISTM, it’s never, ever, “That’s a stupid question”.
/end

Mid-Range Summary

I feel the need to do a bit of wrapping up, not final but just to highlight some points.

The first screed tries to make a simple point: creation of estimates is always on the expense side of the ledger, always, therefore, waste in the formal sense of Lean and Toyota. It is therefore always legitimate to look at getting rid of estimate creation. And it occurs to me here that I’d have perhaps done better to say “estimate creation”, not “estimates” or “estimation”. I might go back and edit the screeds to do that, if I can do it fairly.

The screed is not, emphatically not, trying to say that it will always turn out to be a good idea to get rid of every form of estimate creation. I don’t know that. I’m just trying to make clear that for someone to be on a rampage against all estimate isn’t entirely irrational on the face of it. (I am not, in these comments, imputing rationality, or irrationality, to any individual or group. I’m just saying it isnt crazy on the face of it.)

I wrote the second screed because some people had an abreaction to the word “waste”, which I was trying to use consistently with the Lean and Toyota notions, not in some pejorative sense of grubby brown stuff that you’d hope not to get on your shoes. Creating estimates always has a cost, and almost? always produces no direct value. It is, what we call in the trade, waste. For some reason, I took 14 tweets to make that point. Maybe some of them were waste.

Further Discussion

Here’s some additional discussion, some linked to from above, some based on comments from my Tweeps, some just random stuff that came to me as I wrote this. It’s all intended to illuminate the question of whether or not we’d eliminate all estimates if we could.

Waste

My second day screed goes to this point, but I’d already written this so deal with it. Or skip, I don’t care. It might be waste.

Lots of people objected to the notion that estimates are always waste. Well, I could just plead that it was only a suggestion, but in fact, unless you can sell estimates to someone, they’re not product, they are in fact waste.

(If you can sell them, how can I get in on this excellent gig?)

It might be helpful if you think of creating estimates as an expense. We always want to reduce expense, so it is always of value if we can find a less expensive way to produce our product. So we should always remove estimation if we can.

It does seem to be very difficult for people to stop seeing estimates as having value. I’ve blocked a few people entirely on Twitter, because they seemed to need to become insulting about how anyone could object to estimation. We’ll address a couple of the “estimates have value” concerns here.

Value for Selling

Some folks point out that estimates are used by organizations to decide whether to go ahead with an effort or not. Sometimes the effort is being “sold” or considered internally. Sometimes setting the price is a key aspect of selling an external contract. These estimates may be a step along the way to receiving value, from use of the product, or revenue from the contract. The estimates do not have intrinsic value, so we should consider reducing or eliminating them if we can.

Generally, whether internal or sold, our work’s value should be much higher than the cost of producing it. If a project will save a million dollars a month when finished, and our team costs a million dollars a year–typical for a Scrum-sized team–the project is simply worth doing if we can do it at all. If it took five years to do, it’d be paid off in half a year after completion. If it’s feasible, do it. (But see below, Value for Time.)

Similarly with an external contract. In my possibly atypical experience with external contracts, the way they are really negotiated is that the Sales Department asks Development what the thing will cost, generally without much knowledge of what it is, and then they bid to the client the largest amount they think the client will pay, that is less than what they think the competition will bid, so they’ll get the business.

Since all bidders think this way, usually the bid for the business is quite low in both cost and time. Often–in my experience always–it has nothing to do with Development’s estimate of the actual cost. The inevitable result, of course, is that Development is on the hook for meeting an impossible deadline at an impossibly low cost.

This might have something to do with why many developers, including this one, don’t like estimation. Whatever they estimate becomes the high bar, from which they are to be negotiated downward, often by their own colleagues in the corporation, to the lowest number they won’t just say “I quit” to. Naturally, pro-estimation people reply that of course that’s an abuse but it has nothing to do with estimation per se, but with using estimation poorly. We should learn to make estimates better, explain them better, and manage our use of them better.

Yeah, right. Also you’re not using opioids right, and you should have better will power not to eat all the chocolate chip cookies. It might just be better to keep opioids, cookies, and estimates out of your house. That argument goes on forever, at least based on its performance so far.

But we argue here, persuasively I hope, that if you could get the business by a less costly means than estimating, if you could decide whether to go ahead without estimating, then you should, because it would be less expensive to eliminate the cost of producing the estimate.

It is, of course, a big “if”.

Value for Understanding

Another common argument for estimates, at roughly the story or backlog item level, is that when we disagree over how long something will take, we often uncover differing understanding of the story, and in sorting that out, we get better stories and better understanding.

I am, of course, famously all about understanding between business, customers, and developers. So let’s do have those conversations. And why not do it without the estimates? Or why not do it by a quick show of fingers, never even writing the estimates down?

The value is in the conversation here, not in the estimate. Consider not doing the estimate, or throwing it away after you use it to trigger the conversation.

Value for Learning

Still another argument that can be made, although to my recollection no one made it in this thread, is that if we make a note of how long something will take, and it turns out we’re mistaken, we’ll be wise to take that as a sign to look into what happened. What did we miss? What’s more difficult than we realize? Are there patterns in the work, or in how we work, that need improvement.

One simple example is that the actual work only took three days, but there was a five day delay while we waited for someone with a specialist skill, like a tester or a database god. It could be quite valuable to notice this sort of thing.

Similarly, it can happen that things that would have taken three days early in the project start taking four days, then five days, later on. This is often due to the need for a design improvement that has not been made. It could be quite valuable to notice this.

It can happen when there are an increasing number of interruptions to the team. Everything starts taking longer when people are working on defect fixes, or called away onto other projects, or going to the Mexican place too often and taking longer siestas after lunch.

There is value to discovering these things. Often, however we don’t need formal estimates to notice them. It might be sufficient to make an entry in a tickler file, or right on our task board, when we start a project: if this one isn’t done by Thursday, let’s flag it to be looked at.

We could reduce estimates, or change their priority, or their public faces here, if we choose to. It’s always valid to look at the question.

When? A separate question.

It is fascinating to me what baggage we all bring to these parties. My point here was, and is, that it’s not totally random for someone to look, every time, at whether they can remove the creation of estimates. Every single one has a cost, and if we can get the value without it, we’d be wise to do so.

That is, as someone said, a big “IF”. (It may have been me, I don’t know, I wasn’t paying attention.)

Personally, I am not on a vendetta against creating estimates. I’ve seen it be really horrible, and seen it be pretty OK. I’ve never seen it be perfect. I’ve sometimes seen it be good enough. If I were on a vendetta, it would be one against “horrible”, and maybe a strong leaning against things that aren’t good enough.

In practice, I’m sure there are many points where the return isn’t there for eliminating estimates, and many points where there are more valuable improvements to make. Let me make up an example, related to the one above.

Suppose we’re on a team, using story estimates, and we’re pretty good at consistent estimating, and our actuals are getting worse and worse compared to our estimates. Management is concerned (and in my opinion they’re right to be: we should have already been noticing this and dealt with it.)

We discover in our chats that the reason we’re slowing down is that there are too many defects coming in from outside. There are several actions we could take:

  • Stop accepting defect reports;
  • Stop creating estimates;
  • Start making larger estimates;
  • Improve code quality, perhaps by performing better testing.

It might be really easy to stop creating estimates. It might be tempting to work toward solving our problem that way.

Personally, I think we need to beef up our testing. That leads us to our bottom line, at least for now:

We always could stop estimating, but it’s not always the right thing to do. It’s always legitimate to think about it.

Appendix: Random interesting tweets in the thread

Someone, I forget who, replied:

Worth thinking about it. Just not sure how you can commit to milestones / due-dates then? But if they are not needed I am absolutely in for #noestimates

My reply back was:

Easy to commit to dates: be ready to ship every day. Easy to have best possible value by any date: do things in value order. Impossible to promise fixed scope by fixed date, unless you’re allowed to fudge one or the other.

Allen Holub tweeted:

Just to clarify, in Lean terms, any activity that doesn’t result directly in value delivered is waste. All supporting activities are waste. Realizing that we can’t eliminate all of it, we strive to eliminate as much waste as possible, because it adds cost w/o providing value.

Yes. We’ve touched on this here but since the tweet actually supported my view, I wanted to include it.

Dave (@gundyman) tweeted:

So the argument is more nuanced than simply all “waste” is unacceptable? I would argue that judicious use of estimates when choosing the next most valuable thing to work on is less wasteful than building things without any cost:benefit analysis.

Dave is surely right, given a suitable definition of “judicious”. The point of my tweets and this article, is just that it always makes sense to ask the question, and sometimes, the answer is to stop creating the estimates. Sometimes, it isn’t.

Just to hammer home the bottom line:

We always could stop estimating, but it’s not always the right thing to do. It’s always legitimate to think about it.