[Translation] Estimation — The Best We Can Do

Ron Jeffries is one of the 17 original signatories of the Agile Manifesto, one of the 3 founders of Extreme Programming. He publishes articles in the Pragmatic Programmers e-magazine, and in the April 2013 issue 46 he published the article "Estimation." I asked editor Michael Swaine for permission to translate the article into Portuguese because it's a subject I was going to write about, and Ron, obviously, has already done a better job. There's still much I want to say about it, but for now, straight to the translation of the article:

Two months ago in these pages, Ron Jeffries told us that estimates are evil. Now he’s back to tell us they’re a necessary evil and, done the right way, they aren’t even evil.

Yes, there are many abuses perpetrated by organizations around the notion of estimation. Many developers have suffered grievances from these abuses more than once in their careers.

Unfortunately, this leads to the common naïve view among would-be agile practitioners who are still early in learning: they want to abolish estimates completely. That’s probably not possible, and certainly not ideal. We have the ability to estimate how quickly we can do things, and companies can make better decisions if we share what we know.

Software development isn’t a perfect machine that spits out features quickly. I know it’s comfortable to think we have no responsibility for business concerns like money, time, or dates. But that isn’t true. What we build isn’t isolated — it’s only influenced by some Lord of the Products who decides what we’re going to do and assumes all the risks. Executives are the ones with the final decision, but many of the decisions are better made by the team — and not only in how to do things, but what to do. We have the responsibility to help guide the projects, using our creativity and our special knowledge.

The Agile Manifesto says, “the best architectures, requirements, and designs emerge from self-organizing teams,” and that’s what we meant (my emphasis). Agile developers usually have a good sense of how long things will take, and that’s a valuable component of selecting and refining requirements. Developers need to have the attitude of talking about possible costs of what they’re asked to do.

Concerns About Estimates

There really are several serious problems related to estimating a software job. In a previous article “Estimation is Evil”, I described some of them. Let’s review them:

• Pre-defined work backlogs reduce creativity and inhibit adjusting the project for success.
• Demanding delivery of “everything” on some fixed date is a trick that never works.
• Treating estimates as promises leads to conservative teams and frustrating results.
• Trying to improve the “quality” of the estimates is attention that could give better results if turned toward improving the quality of the product.
• And so on.

In that article, I argued that the result of this focus is “weak Agile.” In essence, teams focused on estimates are usually on the weak side of the balance between cost and value. Better teams focus more on value and less on cost. They still consider cost, because cost is an important component in delivering value. But value is their primary interest.

It’s true that many first-rate teams don’t estimate in the real sense of the term. They work on small stories, small enough that to get a sense of progress you can just count them. They work on the highest-value things first — using whatever notion of value they have. They adjust their vision frequently, and adjust what they’ll work on next according to what is happening. They work to produce a continuous flow of valuable software, and they deliver as frequently as possible, usually daily.

Since estimation is often associated with weak and dysfunctional teams, and since great teams seem to work without estimates, many Agile practitioners strongly resist any estimates of any kind. And it’s a good thing to build a team — and an organization — that is strong enough to work without estimates. But it’s an advanced way of working, never the way to start. It isn’t good to refuse to estimate, or even to feel resentful about it, in an organization where it’s necessary. On the contrary, we need to learn to do it right, in a way that influences the organization positively.

Budgeting New Projects

Now, let’s look at a legitimate need — helping the organization decide whether to proceed or not with a project.

When something goes wrong with our house or car, and we don’t have all the money in the world, we probably get estimates to fix those things. We probably consider alternatives: if the trunk lid is scratched, should we repaint the whole car to match the color perfectly, just spray the lid, try to polish the scratches, or just live with the scratches? We choose the option that seems to be the best use of our money.

Business people budgeting projects have the same problem of allocating funds. They need to consider how to deliver the greatest value possible within the budget. In a small organization trying to create wonderful new products, the concern is even greater. We need to start generating positive cash flow before the money runs out!

In situations like that, we really need to have estimates. We need to know whether it’s a wise decision to go ahead with the new project. Business people already have some estimates in mind: how many people will be interested? What percentage of prospects will become buyers? How much will buyers pay for the product?

But they need to decide: can we start bringing in enough money to stay alive before our money runs out?

The decision-maker knows that all these estimates are estimates, and uses the best judgment to value them. But there’s a key area they don’t know much about: how much of this product can be done, by what date, for how much money? That’s a technical question, and it needs to be answered by technical people.

Yes, of course, we don’t know either. We really don’t know how long it will take. But let’s face the facts — we have a better idea of how long things will take compared to the poor entrepreneur, and they need our help.

I believe we can give a better guess whether it will take a week, a month, a quarter, or a year before we start having a good idea of how quickly we can progress. And this guess, however broad, is a better guess than a business person can give.

We can’t just say “Should we try?” It seems we can say something like:

“Our team costs $10K per week. Let’s start working on the most important, riskiest, most informative parts of your product, and create a sense of how hard it will be and how long things will take. You’ll see us building what you asked for. You’ll see us working. You’ll be able to decide whether you want to keep investing or stop.”

It seems to make sense to say that — unless it’s your $10K coming out of your pocket every week. Then you have more questions. “Will I know after a week? Will I have to wait a whole month to know? Will I know by June? Jeez, guys, that’s about $100K from now until June. That’s a ton of money! Give me a break here! How much is this going to cost?”

We need to take hold of this kind of challenge. We should give the most solid answer we can, even when we don’t have an absolutely concrete answer.

We’re walking on sand. How do we get concrete?

The question is, “How long will it take, and how much money will it cost, to get to a product people can buy?”

We’d like to say, “Well, start spending some money with us, and if you get bored, stop,” but that doesn’t help at all. Can we change this idea a little? Let’s start with a pretty broad estimate just to get a sense of where we are.

We probably already have some notion of whether it will take a week, a month, or six months to do something usable. If so, let’s talk about it. Our investor already has a value in mind that they can spend. Let’s find out how much that is, or get a sense of it in the conversation.

Suppose we imagine that we might get a rudimentary but usable version of the product in six months, and the investor is willing to invest up to $1 million until we achieve positive cash flow. $1 million is roughly a year of our time, and if we take 9 months instead of 6, we’ll need to bring in $1 million in three months to reach positive. Let’s talk about that. How quickly does he expect revenue to grow with the first version? Suppose he thinks revenue will grow quickly, so if we take 9 months, we’re fine. That sounds risky to me, but it seems the project at least looks good enough to explore.

Remember how Agile works. We want business people to be fully engaged in decision-making about spending money based on what they see. So let’s start thinking about selecting features, not just dates.

Estimates That Won’t Make You Regret

“OK, intuitively, we think we can deliver an initial version in six months, and we think that if we take nine months, the project would be viable. It sounds good, but it still sounds risky. We’d hate to see you spend all this and get nowhere, and what we have is still rough guesses.”

“So let’s do this: let’s spend two weeks to produce a more concrete answer. Two weeks will cost you only $20K, which is much less than $1 million. In these two weeks, you’ll actively work with us on the most important aspects of the product. Some will be interface things, some will be driven by business or technical risks we can predict now. At the end of these two weeks, we decide whether we want to continue. Our job will be to show you, concretely, what we can build that convinces us of whether to proceed or not. Your job will be to guide us by describing what you want, and to work with us to identify risks and concerns.”

“If after these two weeks, things look bad, we’ll know it, and we’ll recommend you stop. If things look good by then, we’ll decide together what the next decision point will be. It could be a month from now, or three months from now. Frankly, we’re perfectly happy to do this every two weeks.”

“Yes, that’s right. Every two weeks we’ll talk with you about what to do next. Let’s do it and show you. If it’s good enough, we continue. If not, we stop.”

“That way, your risk will never be greater than another $20K. You can decide whether to use that money to get more information, to redirect your efforts, or to see whether you should spend that money some other way.”

“Can we work this way?”

If he says yes, let’s start. If he says no, we need to find out why, and even whether this project is for us.

This is definitely estimating, and it’s a kind of estimating that we can do in conjunction with our business people rather than in conflict with them.

We estimate, with some certainty, that we can produce useful information in two weeks. If we don’t think we can do that, we’d better suggest four or six or eight weeks.

More than that, we estimate that a viable product is probably possible in six or nine months. If we had no idea, or worse, if we honestly doubted it, then we can’t legitimately invite him to find out — at least not on the terms above. We owe it to him to say “Frankly, this looks like a two- or three-year project to us. We could be wrong: here’s what we need to learn to find out. Here’s what it would cost to find out, and our best guesses now are that the answer will be bad news.”

Sometimes we have a good idea of what we can do. Sometimes we know less. Either way, by estimating what we know, we can design experiments — investments — that improve our ability to decide what to do.

When we’re talking about spending other people’s money, I think we owe them to think and act this way.

This Is Estimation, Not Negotiation!

An estimate doesn’t have to be “This project will be finished on Tuesday, May 14, at 2:35 PM.” An estimate is supposed to be expressed with a range of possibilities. It would be perfectly OK to say something like, “We see no possibility of this being done before April. If everything goes perfectly, we can be ready by mid-May. Based on our experience, we’re thinking June, maybe July.”

Whether we say this or not, chances are we know it, or at least suspect it. And if that’s what we think, the project needs that information. However, if we put it that way, we’ll be pushed back. Someone will challenge us to prove, without a shadow of a doubt, that we can’t deliver by April 30, and if we prove that, they’ll say “How about May 5?” Bah, we hate it when they do that. So how can we deliver information the project needs without playing this game?

Move from Estimated Date to Estimated Velocity

Let’s use the Five-Card method from previous articles, not to estimate a date, but to break the whole project into sub-stories small enough that our team does, say, five of them in two weeks. Of course we can end up having only three done. We may have six, but we doubt it. Then we arrive at an estimate in terms of velocity:

“We broke the project into smaller stories. We believe that with stories of this size, we’ll be able to do between three and five every two weeks. And at the end of a two-week period, everything we do will be visible, tested, integrated, and working. So whether it’s five or six or two per week, we’ll know, and you’ll know.”

“If you can remove or defer some of these stories and still have a viable product, you’ll have the product sooner. If you can simplify, you can have the product sooner. If you add stories, or make things harder, you’ll delay the product to later.”

“It’s up to you. We can break things into this size, we can guess our velocity now as three items every two weeks, and you’ll know every two weeks what’s really happening. You can use that information to decide what to do, what to defer, in order to get the best product by whatever dates you choose.”

Help Management Learn About Velocity

Now management may still want to negotiate about this with us. If they try to add up the numbers to get dates, and then start adjusting the dates, don’t negotiate: turn the conversation back to the rate of progress. “The date is up to you. If you choose to do more, it’ll be later. If you choose to do less, it’ll be sooner. We think we’ll do between three to five items every two weeks. We may be wrong: if we are, you’ll know as soon as we do.”

Someone may try to push velocity. “Can’t you do seven every two weeks? Then you could finish on time.”

Remember how Agile works: developers work at a sustainable optimal pace; developers aren’t responsible for the dates; the business side owns the dates, and owns the responsibility of reaching those dates.

The developers’ job is to deliver at the best possible pace: “We think we can do three to five. If we happen to go faster, you’ll know. If we’re slower, you’ll know too. When we finish depends on that, but depends even more on how little you give us to do. What goes into those dates depends on you. You should plan on three to five items every two weeks, and check what’s actually happening.”

This can press more than once to go faster. But we have the facts at our disposal, as they are. “Based on our experience, we’ll have three to five done. It wouldn’t be wise to assume anything greater than that, because it probably won’t happen. If something happens that makes us go faster, we’ll all know it and you can select more items into the version.”

All of this, of course, has much more to do with communication, not estimation, and emphatically not negotiation. The estimation was trivial: we did it right at the beginning when we separated the cards. Now we’re communicating what we know, what we guess, what we believe.

We give management our best estimates and production rates, and we commit to them, improving as we evolve. We continue to make it clear that the business side controls the dates by choosing how much work they ask for.

Optimizing the Product

Whether you’re in favor of estimates or not, you should know that Agile is about building products incrementally, in good condition, from day one to the last day, and extracting value from it as early as possible. That requires great technical skills, but technical skills aren’t enough. The people paying for our work need to allocate their resources. They need to manage their money, and they need to coordinate our work with activities and stakeholders outside our team.

To do this efficiently, they need information about how long things will take, which translates into how much things will cost, and how long it will take for us to start getting our money back. They need the information we have to do this work well. The fact that our information is vague, flawed, and uncertain isn’t a reason not to expose it. We need to put our information in their hands, and do it in a way that gives them the best opportunity to use it as well as possible.

Refusing to estimate isn’t the right thing to do. Estimating is necessary, and effective communication of the estimate is necessary too.

The best thing to do is to develop small features at the best sustainable pace possible, and use the information generated to help business people decide what to ask for, and what to defer. To do this, we need to estimate. We break stories into small estimable sizes, and we estimate our rate of delivering them. This type of estimation isn’t evil at all: it’s incredibly useful and is what the best agile teams do.

Ron Jeffries has been developing software longer than any living person. He holds advanced degrees in mathematics and computer science, both earned before negative integers had been invented. His teams built operating systems, compilers, relational database systems, and several large applications. Ron’s software products generated more than half a billion dollars in revenue, and he wonders why he didn’t earn any of it.

Send feedback to the author or discuss the article on the magazine forum.