Avoiding the Infinite Abyss

—Andy Hunt

11/01/2010
Published in PragPub Magazine

Estimating is never easy. In agile projects we try and get a better feel for estimating over the course of a project as we get more familiar with the pace and capabilities of ourselves and this particular team and technology environment. On most projects we want individual team members to come up with estimates for their own tasks, the ones they’ve selected from the current project backlog. That puts the onus of estimating on the person who actually has to do the work, a nice touch of straightforward reality in an otherwise messed-up world.

But for programmers new to this style of working, or new to the team or to the technology, trying to decide on how long a task might take is kinda like trying to pick a winning lottery number: billions of choices, only one right answer.

I was visiting a newly agile team last week, and this was an area of agility they were struggling with. I asked what units they were estimating in (there are so many colorful units in use these days). Bottom line was, they were estimating in hours. That meant that for each estimate, you had around two hundred possible answers using whole hours within an iteration. Turned out you could also specify fractional hours, which meant effectively an infinite number of allowed answers.

No wonder it was hard to decide on an estimate.

Less Is More

“Too many” choices is a mental turn-off; it’s a demotivator. When faced with too many choices in a retail store, consumers choose to not buy anything at all.[1] Too few choices is no bargain either. I can easily imagine a large, formerly waterfall-based bureaucracy mandating that “all agile estimates shall be equal to Three. Four shalt thou not count, nor two, excepting that thou then proceed to Three. Five is right out.” [2] Sigh.

You need a minimum of three alternatives to make a real choice, but you don’t want too many more than that. In the Jam study above, consumers clammed up with 24 choices; that many choices is simply overwhelming.

So for estimating, try to constrain yourself to something like 3 or 4 choices, perhaps:

One hour
One day
Three days
One week

Now you’re not facing an overwhelmingly infinite choice amongst all the rational numbers, but just a choice from a set of three or four. You’re not trying to codify exactly how long it might take, but you’re taking a pretty good stab at sorting it into a reasonable-sized bucket.

If the task you’re facing is longer than your maximum (one week, in this example), then it’s too big. Break the task down into smaller tasks. Yes, you can refactor the task list, and smaller tasks are easier to estimate correctly.

Constraints Foster Ingenuity

The Beatles recorded some of their most complex works on a simple four-track recorder (yeah, there’s an app for that now.) Imagine if your project had no deadline at all. Think it would ever get done? What about your own hobbies and personal projects that don’t have a deadline? How are those coming along? Constraints—fewer choices—are a good thing, and foster ingenuity.

That’s why timeboxing, in all its various forms, is so popular. Whether it’s a sprint, an iteration, or a Pomodoro, putting a strict limit on time forces you to make the hard decisions. You don’t have forever; you don’t even have a month. You have a short period of time—now—to do what needs to be done. There’s no luxury in waiting, hoping for something better to show up, or for a miracle to come riding over the horizon. It’s just now. So given that, how are you going to go about it?

This month of November, we’re encouraging everyone to write—every day, for one month. You wanted to write that book, that program, or that rock opera? Now’s your chance. But just now, for one month only. Set yourself this deadline: what can you accomplish each day, each week, for a month?

Without at least some constraints, you’re just staring straight into infinity. And that’s a little rough on a Monday morning.

Something to think about.

[1] “When Choice is Demotivating: Can One Desire Too Much of a Good Thing?” Journal of Personality and Social Psychology, 2000, Vol. 79, No. 6, 995-1006

[2] Monty Python and the Holy Grail. I had no idea those guys read the same project documentation I’ve seen.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.