PM Articles > Kent McDonald > The Movie Phone Approach to Estimating

The Movie Phone Approach to Estimating

by Kent McDonald

There are a few activities surrounding project work that annoy almost everyone, yet are important for putting together coherent plans. The prime example is probably estimating. For starters, you are trying to figure out how long a project (or part of a project) will take with the least information you are ever going to have. Then, when you do come up with an estimate, your sponsor tells you it is too much, or too long, because they already have a number in mind.

To deal with this, I've started using a new approach I call "Movie Phone Estimating" -- based on the Seinfeld scene where Kramer acts as the Movie Phone guy. Here's how Movie Phone Estimating works.

As the product owner for the Agile Alliance Conference Submission System, I have to identify a budget for work to the submission system in preparation for Agile2014. The work on the submission system is usually funded as part of the budget for that year's conference. The Executive Director of the Agile Alliance was putting a budget together while I was compiling the feature list. One of his assumptions was a particular dollar amount in the budget, but he said I should let him know if it was enough.

If there was already a number in the budget that was not provided by the team, I reasoned, then it was probably representative of what the executive director thought was reasonable. In effect, it was the target. I decided to treat that dollar figure as a constraint. There was minimal work necessary to get the submission system ready for Agile2014 and most of the items on our list were improvements. I compiled the backlog and sent it to the team for estimating.

The team estimated using a range that represents a 90% confidence interval, which means that 90% of the time, the actual time to develop the feature would fall into the range provided. I asked the team to estimate each feature while I grouped features together into A, B, and C buckets. The A bucket represented things I felt were absolutely necessary to finish for Agile2014, and the B items would be really nice to have. Everything else went in the C bucket. To simplify decisions, I also sequenced the items in each group. The goal was to see if we could get all of the A items done within the "target" budget.

When I got the estimates back, I added up how much each feature would "cost" using the high end of the range for each one, then summed the A group. The total was a little bigger than the budget target, so I reviewed the list and moved a couple of items down into the B group until I was below budget.

I could have gone back and asked for more money, but I knew I would have to explain the request, and at this point the argument was not worth having. After all, these were estimates. If I stood a pretty good chance of getting everything I needed for an acceptable cost, I was better off getting started than arguing over what would have amounted to a small amount of the total budget. Plus, using the upper end of the estimate scale made it likely that some features would not take as long as the team thought. (And yes, I also realized some would take longer.) So in the long run I thought there was a good chance we'd be able to get some of the B items done too.

I told the executive director that we could just use the budgeted number. Then I told the team to get started using the spreadsheet I created while grouping the backlog items, and to let me know every so often how much budget they had left. The team figured it would be easiest to indicate how many hours they spent on each item, and I added a calculation to keep a running total. We ended up delivering all of the A items, and half of the B items. Plus, along the way we made some significant improvements on the overall submission and selection process.

As an added benefit, we didn't have to spend an inordinate amount of time debating the estimate and the resulting budget number. There was obviously a target implied in the budget, so we estimated to sanity check whether we could get done what we needed to within that constraint. Then we used the time that ordinarily would have been spent arguing about the estimate to start delivering features, while maintaining the flexibility to change which features we worked on and ensure we were delivering the right changes for the submission system.

So the next time you find yourself being asked for an estimate, don't try to guess what zip code your sponsor is punching into their phone. Simply ask, "Why don't you tell me what you want the budget to be?" Then be flexible about the scope that you deliver to meet the objectives you are setting out to accomplish.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.