The Movie Phone Approach to Estimating

All things eventually go back to Seinfeld. Here's how Kramer's botched attempt to act as the Movie Phone guy inspired an alternative approach to estimating.

I originally wrote this article for Project Connections, one of my first outlets for article writing that sadly is no longer around. Fortunately, I was able to get all of my pieces back from the site and am able to freshen up my favorites for republishing. Enjoy!

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’re trying to figure out how long something will take at your point of maximum ignorance. 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 use an approach I call “Movie Phone Estimating” — based on Kramer’s failed attempt to act as the movie phone guy on Seinfeld. scene where Kramer acts as the Movie Phone guy.

Here’s the story of when I first started using that approach.

Setting a budget for yearly work

As the product owner for the Agile Alliance conference submission system, I had to identify a budget for work to prepare the submission system for upcoming versions of the Agile20XX conference. The work on the submission system was usually funded as part of the budget for that year’s conference.

The Agile Alliance executive director put a budget together while I compiled the backlog.

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 not provided by the team, I reasoned it probably represented what the executive director thought was reasonable.

In effect, it was his target So I decided to treat that dollar figure as a constraint.

Estimating for Agile2014

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 to estimate.

Estimating and organizing the backlog

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. (Hat tip to Todd Little) .The A bucket represented things I felt were absolutely necessary to finish for Agile2014. The B items were things I considered 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.

Use the budget as a constraint

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 we stood a pretty good chance of delivering everything we needed for an acceptable cost, we were 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.) There was a good chance we’d be able to get some of the B items done too. So I told the executive director that we could just use the budgeted number.

Delivering what we needed, and more

So the team got started on the Group A backlog items, and 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.

Estimates as a sanity check rather than debating point

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.

What don’t you tell me how much you want to spend?

So the next time you find yourself being asked for an estimate, don’t try to guess what zip code your sponsor punched into their phone.

Simply ask, “Why don’t you tell me what you’re willing to spend?” Then be flexible about the scope that you deliver to achieve the outcome you’re setting out to accomplish.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent J. McDonald
Product Management Writer