(2013-02-06) Jeffries Estimating Is Evil

Ron Jeffries says Estimating is Evil. (No Estimates)

Teams applying Agile Software Development ideas almost always get some improvement... Teams that are getting good but not great results are our main concern here... these teams are often excessively concerned with estimation, and with living up to their estimates.

Does it surprise you to know that if a team has more work thrust upon it than they think they can accomplish, they generally fall short? It shouldn’t. Does it surprise you to know that it is common, only two weeks after someone pushed more work on them, that same someone expresses disappointment that the team has “broken its promise?” (Commitment) It shouldn’t... Teams that are asked to do more than they can do will say, “We’ll try.” And they will try. This rarely works out well. To be sure of getting done, they’ll begin to over-estimate everything. In order to get done quickly, they’ll cut back on important aspects of work you can’t see.

The Agile Manifesto calls for Working Software. Take the next problem, solve it with working software. Really solve it, which means getting that solution in the hands of the people who need it. It’s not about planning, predicting, and projecting. It’s about choosing, building, and providing.

It seems that “they” (Gold Owner) often want to know how long something is going to take, and how much it will cost. My view is that “they” don’t even know what they want, so we bloody well can’t possibly know how long it will take. However, “they” are often powerful and have the money we need, so we need to answer their question, even though we cannot... Most of the time, “they” know how many people they’ll give us, and how much time. They do that head-shaking thing until we “estimate” the numbers they have in mind. So we should turn the question around. “How much did you want to spend, and when did you hope to see the product?” Then they tell us, and we decide whether we can do something reasonable within that budget... It’s pretty much guaranteed to be wrong. But it might be large enough to let you get started, and start making fine-grained decisions on what to do next and what to defer. Do the Agile thing, producing a running system every couple of weeks... Why not have a full product that does very little at first (MVP), then more and more?

Get yourself a “customer” or “ProductOwner” (Goal Donor) who can make decisions on what to do next and what to defer. Work in very short cycles. Two weeks. One week. One feature at a time, in two days. Short. Do features from most important to least. Every time a feature is done, or at least every two weeks, build an integrated, tested version of the software. Show it to everyone. If possible, get it to users who need it. If your software is slated to save lives, save some lives with it. Observe what happens. Factor that into what you do next. You’re shipping a complete product now, every week or two. When the deadline arrives, it’s just another shipment. If everyone is satisfied, and likely they will be, stop. If they want more, you’re all set to do more, every two weeks.

This approach shortens all the cycles that delay getting value. It shortens the communication lines between the people who want things and the people who do things. It shortens the communication lines between the people who create things and the people who use them. Take the most important ideas, build them quickly, get them out there.

This is the best anti-estimating thing I've read.

Apr03: ok maybe not evil? What we build is not solely the purview of some Product Overlord who decides what we’ll do and takes all the risk. The business people may make final calls, but many of the decisions are best made by the team—not just how to do things, but what to do. We do have a responsibility to help guide the project, using our creativity and our special knowledge... It’s true that many top teams do not estimate in any real sense of the term... it’s good to build up a team—and an organization—that is strong enough to work without estimation. But this is an advanced way to work, not the way to start. It’s not good to refuse to estimate, or even to resent it, in an organization where it’s needed. On the contrary, we need to learn to do it well, in a way that influences the organization positively.

Now, let’s look at just one legitimate need, helping the organization decide whether to go ahead with a project... Suppose we kind of think that maybe we could get a rudimentary but usable product in six months, and the investor is willing to invest up to about a million dollars to get to positive cash flow... We want to get our business people fully engaged in making live decisions about spending money based on what they see. So let’s get to thinking about feature selection, not just dates. “So let’s do this: Let’s take two weeks to produce a more concrete answer... “Yes, that’s right. Every two weeks we’ll talk with you about what to do next. We’ll do it and show it to you. If it’s good enough, we’ll continue. If not, we’ll stop. That way, your risk is never more than another $20,000.”... We estimate, with some certainty, that we can produce useful information in two weeks. If we think we can’t do it, we’d better suggest four or six or eight weeks. Furthermore, we estimate that a viable product is probably possible in six to nine months. If we have no idea, or worse yet, we sincerely doubt it, then we cannot legitimately invite him to find out—at least not in the terms above. We owe it to him to say, “Frankly, this sounds like a two- or three-year project to us. We could be wrong: here’s what we’d have to learn to find out. Here’s what it would cost to find out, and our best guess right now is that the answer would be bad news.”

This is Estimation, Not Negotiation! They’ll say, “What about May 5th?” Bah, we hate when they do that. So how can we give the project the information it needs without playing this game? Move from Date Estimation to Velocity Estimation. “It’s up to you. We can split things down to this size, we can guess our speed now at about three items per two weeks, and you’ll know every two weeks what’s really happening. You can use that information to decide what to do, and what to defer, so that you can get the best possible product for any date you pick.”... If they add up the figures to get dates, and then start trying to adjust the dates, don’t negotiate: turn the conversation back to the rate of progress... Someone might try to push the velocity. “Can’t you do seven every two weeks? That way you could get done on time.”... “Based on our experience, we’ll get between three and five done. It would be unwise to assume anything higher than that, because it’s not likely to happen.”

It still sounds like he's validating estimating 6mo in advance, which you then get held to. (Except of course you immediately start changing. But that exec probably still isn't going to be happy...) I Commented here.