Estimating and Planning Are Necessary for Maximizing Delivered Value

Because I'm so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, "Estimating is waste! Don't do it!" The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value of estimates and plans (and the shortcomings of poor estimates and plans).

Let's consider that perspective for a moment. How many significant things in your personal life would do without at least some planning first? I doubt you would plan a wedding, a relocation to another city, a holiday trip, or any such event without first engaging in some amount of planning.

Suppose you are considering a first-ever trip to Italy. You would plan that--which cities? how long in each city? what's your budget? and so on would be some of the questions you would consider. Now suppose you are planning your one hundredth return visit to the city in which you grew up. You will even plan this trip--even if the extent of that planning is to decide you don't need to plan at all.

Planning is the act of thinking about the future. Sometimes that future holds risk and uncertainty. In those cases we plan more than when the future is highly predictable as a hundredth visit to your childhood home town would be. When a future activity is highly predictable, planning may consist of nothing more than a few milliseconds of rejecting the need to plan further.

Of course on a software project it is rarely this simple.

What about estimating? Do we really need to estimate? Yes, because estimating is a pre-requisite to planning. You cannot plan without estimates in mind. Those estimates may be very informal and very implicit. As I write this I am on a flight to California. Before boarding the plane I got cash from an ATM. I estimated my upcoming need for cash to do that. $200 should do it. That estimate took less than a second and I was perhaps not even conscious of it, but it was made.

When a product owner says, "I'd prefer to add this feature rather than that feature," the product owner is acting with at least some implicit estimate (perhaps guess) of how long each will take. When a programmer chooses late in the day to fix a bug rather than start a new user story before going home, that programmer has made an implicit estimate that fixing the bug fits better with the hours left in the day.

Teams that say, "We won't estimate. We'll just make every user story the same size," are estimating. They are estimating that this user story is the same effort as all other user stories. I'd even argue that it's harder to make each story the same size than it is to use a small range of effort sizes on various stories.

These estimates must be made. Yes, they can be subconscious but they are made. Those who blog and post to newsgroups saying "estimating is waste, don't do it" are ignoring these types of estimates.

But are these casual, perhaps subconscious, estimates OK? Wouldn't teams be better with formal estimates?

Perhaps but not in all cases. A team should estimate and plan only to the extent that further investment in estimating and planning will lead to different actions. If you will do the same thing even if you estimate or plan more, stop. But if further planning is likely to lead to better decisions (more confidence in a delivery date, better prioritization of functionality, or so on), then estimate and plan further.

The right amount of estimating depends on the decision you need to make. A small, low-risk change may need little more than a quick conversation. A large investment with significant uncertainty deserves more thought.

The goal is not to make estimates perfectly accurate or plans perfectly predictive. The goal is to understand enough about the likely effort, timing, and risk to make a good decision.

Estimating and planning should earn the time spent on them. Keep them as lightweight as the situation allows, and stop when more detail is unlikely to change what you do.

Last updated February 6th, 2012