Agile Focus

Much has been written on the subject of how to estimate the effort involved in developing software products. Some Agile teams use Story Points as their estimation units. Others estimate in Ideal Days. Still others use one of these plus Task Hours to help refine their estimates. Planning Poker is a popular method for quickly arriving at group consensus on estimates.

My own earliest attempts at estimating predate the Agile era by a couple of decades. In the beginning I used a technique that has probably been tried (with varying degrees of success) by many others:

1. Break the development effort into as many small tasks as you can think of
2. Estimate each of the tasks in hours
3. Add all the estimates together
4. Apply sufficient “padding” for comfort
5. Hope the boss buys it

Estimation’s main purpose

There’s no doubt that the more recent Agile estimating techniques are much better than what I started out with, and I’m glad that so much effort has been put into developing these methods. Even so, I believe it’s easy to lose sight of the purpose behind estimating, which can be summarized as follows:

The purpose of estimating is to provide the customer with a predictable development schedule.

Predictable is the operative word here. With a truly predictable schedule, the customer can derive the information that is most important from his or her point of view. Given a predictable schedule, the customer can answer important questions, such as:

• How much will this development cost?
• Will we be able to hit the market window?

In other words, the customer is probably not interested in the accuracy or precision of your estimates in and of themselves. The customer is more likely interested in the predictive power of your estimates. Given that, you want to focus your estimating efforts on things that provide predictability.

Duration should be derived, not estimated

I like to encourage teams to focus on estimating User Stories in Story Points, and to discourage them from estimating tasks at all, largely because coming up with Task Hours doesn’t seem to contribute much to the goal of providing the customer with a predictable schedule. Admittedly, estimating Task Hours may help to inform the team about how good or bad it is at estimating duration, but that’s a metric that’s not directly useful to the customer.

What is directly useful is duration that is derived from a team’s demonstrated velocity. Given a velocity in units of Story Points per iteration, plus knowledge of how many Story Points remain in a development effort, the customer can quickly and easily predict the development schedule.

Anyone with even the slightest exposure to eXtreme Programming has heard the phrase “do the simplest thing that could possibly work.” While this precept is typically applied during the process of writing code, I’ve also heard it mentioned during design discussions. I bring it up myself during estimation sessions as a reminder to estimate the simplest implementation of a user story one can imagine.

I’ve also heard it misquoted as “do the easiest thing that could possibly work” and even “do the quickest thing that could possibly work.”

It’s not necessarily the easiest thing

Although the simplest thing that could possibly work might sometimes also be the easiest thing, it often is not. For example, the easiest thing might be to copy and paste a section of code in order to duplicate its functionality in another part of a program. But is that the simplest thing? I believe it is not.

It’s not necessarily the quickest thing

The simplest thing that could possibly work might sometimes also be the quickest thing, but there aren’t any guarantees. The use of short variable and method names might be quicker (because it saves typing time) than the use of longer, more meaningful names, but is it simpler? Again, I don’t think so.

What does simple mean?

Here’s my working definition: Something that is simple is neither complex (meaning having more parts) nor complicated (meaning difficult to understand).

In the first example above, the easiest thing is not the simplest thing because doing the easiest thing (rubber-stamping the code) introduces complexity.

In the second example above, the quickest thing is not the simplest thing because doing the quickest thing (using short names) introduces complication.

Conclusion

If you want to do the simplest thing that could possibly work, look for a solution that is both easy to understand and lacking in unnecessary complexity.