How to Avoid Three Big Estimation Traps

How to Avoid Three Big Estimation Traps

I bet you need to estimate how large your project or program will be, at the gross level: “It's bigger than a breadbasket. It's smaller than a person on the moon.” More likely, “It's about x people for about y months with this percentage confidence.” Or, you use a date range, as I suggest in Manage It! Your Guide to Modern, Pragmatic Project Management.

But that doesn't mean you don't have estimation traps. Here are three big traps I've seen:

Trap 1. Someone wants you to estimate a large program at some time, and they think that estimate is good forever and ever, amen.

Ahem. Times change. People change. Technology changes. The platform changes. Why wouldn't your estimate change, too? Consider delivering your estimate with an expiration date: “This estimate will expire in 60 days.”

Trap 2. You thought this backlog item was small. Instead, it turned out to be something you needed to spike.

Murphy's Law happens on projects and programs. Sometimes, your estimates are just guesses. What's the best thing you can do? Expose them as guesses as fast as you can. Then, manage the risk.

Estimates have built-in variability. The smaller you make your stories, the less variability you will have. And, every so often, something will still surprise you. Or, you will say, “We need to spike this, because we have no idea what this beast is.”

Trap 3. Someone wants you, as an agile program manager, to add up all the estimates from the agile project teams and “commit” to when the program will be done.

If you have started an agile program, you have several options, but adding together relative estimates is not a good idea. Relative estimates means that one team's t-shirt sizing is different from another team's poker planning, which is different from another team's ability to swarm around features in flow, and not bother estimating at all.

But what do you do with a reasonable request from your management?

  • You can create a product backlog burnup chart, instead of an estimate.
  • You can ask, “How much do you want to invest before you want to stop investing, to manage the money risk?”
  • You can say, “Please explain what risks you want to manage, and I will explain how we, as a program, are managing them.” Your management does need to know what you will deliver, and when. Seeing your progress in the form of demos and burnup charts might help more than estimates.
  • You may even want to ask, “What value do you want to see before we stop? We might be able to provide a SWAG (Scientific Wild Tush Guess) in a short time for that.”

Have you seen or experienced other big traps? Let me know. I'll write more about them and help you avoid those, too.

Where Johanna is Speaking

If you liked this article about estimation traps, you might want to know about my November workshops in Israel. Estimation is a part of program management and is a part of what might need to change in your organization. I will be teaching several workshops, including one about agile program management and one about organizational change. See A Week with Johanna. Please do join me.

July 28-Aug 1, Agile 2014, Orlando

Sept. 2, Webinar Agile Program Management: Networks, Not Hierarchies


New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

See my books page for my books. If you see one that interests you, and you would like me to speak about it, let me know.

See my workshops page for my workshops.

I keep my blogs current with my writings: Managing Product Development, Hiring Technical People, and Create an Adaptable Life.


© 2014 Johanna Rothman

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: