Fearless Estimating: Agile Project Management Answers

Some time ago, I came across a cartoon that sums up thecurrent state of affairs on most projects. Here’s how it goes.

A programmer is asked for his workestimate on a task.

• He thinks: “Two hours.”

• He says: “Two days.”

• The project manager tells his boss:“It’ll take him two weeks.”

• The boss tells her boss: “Twomonths.”

• The CEO is told: “Two years.”

We tend to chuckle at this because it’s funny … and sadlytrue. In this case, everyone’s safe. It’s hard to envision a situation inwhich, no matter what goes wrong, the task doesn’t get completed on time. Evenif the programmer is off in his estimate by 100 percent, he’ll still beat his twoday delivery promise. In fact, everyone in this story is safe because they’veall padded their estimate of the project by a gigantic margin.

The trouble in this case is that no one (except theprogrammer) is working with real information anymore. And it’s just as likelythat the project will get cancelled because it’s going to take too long.

Humans are often motivated by fear and usually this is agood thing. After all, fearing stampeding elephants kept our ancestors alive.Sometimes the fear makes us act too cautiously though. Most of us want to beperceived as efficient, helpful contributors to the team. We fear disapprovalfrom colleagues and our leaders, so we make time estimates that show us in themost favorable light.

This fear-based mode of operating is all too common inproject-based work, and its roots are understandable (and lamentable). Weaccount for the unknown by padding our estimates. Everyone does it. It’s basedin fear of the consequences when we fail to meet our commitments.

One of the key shifts that a team adopting agile project management will need to make is to shed this fear-based mode ofestimating the work at hand. It requires both a behavioral and a cultural shiftamong team members, by the team leader (or Scrum Master) and by thestakeholders and project sponsor. For, after all, an estimate is merely anestimate.

The first day of a project is the worst day on which to give anestimate

In fact, every single day that we work on a project, welearn more about it and are better able to make an estimate of when it will bedone, what it will cost, and what it will look like. Of course, we rarely havethe luxury of not giving a project estimate until the very end. But I alwaystell this to the project sponsor. In fact, the first step in shedding the fearis to confront its source at the very start of the project. You’re going totell me about the project, and I’m going to give you a very wide range ofpossible outcomes. As we kick off the project, we’ll narrow that range. After werelease a first iteration, we’ll narrow that range some more. (Or maybe not, depending onwhat we learn.)

Marry the top-down and the bottom-up estimates

For sure, it’s helpful for the project sponsor to let theteam know what’s desirable and what’s possible in terms of budget, timeline,and outcomes. There’s no sense in scoping out a grandiose $250,000 project whenthe budget will bear only $25,000.

Once you’ve gotten a few projects under your belt, you’llhave a sense for about how long the next one will take. You’ll use thisexperience to make a quick high-level estimate of each new project youencounter, adjusting for familiarity with the topic, the audience, the projectsponsor, the technology, and the like. This experience-based estimate, alongwith the project sponsor’s budget in mind, gives you the top-down estimate.

You’ll then break down the bigger project into smallerpieces, even down to the task level. As you build up this project plan from thebottom-up, you check it against the top-down estimate. When the two don’t meet,you’ll have to have a conversation with the project sponsor about scope,budget, time, and expectations.

Estimate in small increments

The more you can break a project down into small increments,the more accurate your estimate will be. When I teach agile project managementto instructional designers and developers, I like to use the jelly beanexercise I learned from Rich Sheridan at Menlo Innovations in Michigan.

I fill a two-ounce shot glass with jelly beans and ask thegroup to estimate how many jelly beans are in the glass. I’ll ask for about 10responses, then calculate the mean (average) and the range between the highestand lowest responses. When I reveal how many jelly beans are actually in theglass, we find that the average is usually off by quite a bit, and the range ofanswers is pretty wide.

I then bring out a tall glass tumbler and we do the sameexercise. Then I bring out a big glass water pitcher filled with jelly beans.As you can imagine, the average is farther off and the range is wider as thecontainer gets larger.

What does this have to do with project management? It’seasier to estimate in smaller batches. You’re more likely to know if yourestimate is way off if you’re counting a small glass full of candies as opposedto the gigantic pitcher. You get more practice and more feedback when you’reestimating smaller pieces. That’s why agile projects and agile tasks are brokendown into the smallest increment possible.

Use an estimating scheme that accounts for the uncertainty inherentin large estimates

Some project estimating approaches force a false sense ofprecision. If my Gantt chart calculates a project at 27.83 days, what does thatreally mean? It’s calculating a false sense of precision, as though I couldactually calibrate my work to the hundredth of an hour, over a month out fromtoday.

Agile teams use one of several estimating schemes that helpsus deal with uncertainty: powers of 2 (2, 4, 8, 16, 32…), the Fibonaccisequence (1, 2, 3, 5, 8, 13, 21, 34…) or even a simple small/medium/largeapproach. It doesn’t matter which one you pick. The point is simply that thedistance between each increment increases as you go up.

When estimating specific tasks, we work in hours: two hours,four hours, eight hours, and so on. When we’re estimating larger components ofwork, we’ll work in units of days or weeks. The scheme allows us to veryquickly make an estimate that both accounts for uncertainty and avoids a falsesense of precision.

Prepare for the unexpected

This will sound a little counterintuitive after all thepreceding: make an estimate for the unexpected.

Your computer crashes and takes days of work along with it.The project scope changes. The underlying business need changes. The softwareyou’re using upgrades. The subject matter expert leaves the organization. Ittakes seven attempts to get the graphics just the way the project sponsor wantsthem. A key team member gets pulled to another project.

Something will happen. You just don’t know what it is. Butyou can plan for it.

In old fashioned project planning, this is called yourcontingency factor. It’s a block of time (and/or money) that you set aside forthe unexpected. Low risk projects have smaller contingencies than higher riskprojects.

The point here is that the contingency factor isn’t bakedinto every task, but rather held out on its own. That way, if you find thatyou’ve used up all your contingency time and you’re only a few weeks into theproject then you’ll know you need to adjust.

Keep your finger on the pulse

An estimate is neither a bid nor a promise. Estimates arejust that: estimates. And that’s precisely why close tracking and goodcommunication are essential.

Agile can handle inaccurate estimates much more readily thanit can handle poor communication. As soon as someone realizes something is awrywith the task or the estimate, he or she must speak up. You can make alternateplans and the project will continue. However, when a team member doesn’t alertothers to a potential problem, all the other tasks are put in jeopardy and theproject can grind to a halt. If an employee needs to fear anything, it’s theconsequences of not reporting a problem.

At the project level, agile teams report status to projectsponsors every week or every sprint (usually two-to-several weeks). If yourtime reporting system or agile software allows for it, you can easily trackestimated hours vs. actual hours. This lets you head off problems before theygrow too large.

Whether you’re using agile methods or a more traditionalproject management approach, you’ll need to estimate your work. Before you addin that extra measure “just for safety’s sake,” remember: never fear! Estimatesmall, adjust frequently, and keep your finger on the pulse of the project.

Editor’s Note: Hear Megan speak on agile project management atLearning Solutions in March!

Megan Torrance, the author of this article, is leading apre-conference workshop and a concurrent session at the Learning Solutions Conference & Expo 2015, March 25 – 27 in Orlando.

• Pre-conference Certificate Program: Using AgileProject Management for eLearning
• Concurrent session: Adopting Agile Requires aCulture Change—Are You Ready?

Registerby December 19, 2014 for a $200 discount on the conference fee!