Zombie Estimating Techniques

Zombie Estimating Techniques

Since we all know zombies don’t count, we’re going to assume you are the poor sap trying to get away from said zombies.  But what are your chances of survival?  Do you have enough ammo?

Let’s assume your survival is the project.   Since a project is a temporary endeavor, we’ll go with that.  Our goal is not necessarily to create a unique project, service, or result, unless you count killing zombies.

How big is that unthinking horde or zombies slowly making its way toward you?

Do you have enough ammunition to kill them all, before they get to you?

Now, I don’t know about you, but my estimating skills suck.  We’re in trouble unless the unit of measure are digits on my body or comparing something to the size of my coffee cup.  But that’s ok. We have bigger things to worry about. I mean, we do have a horde of flesh eating zombies coming after us. So, let’s talk about two simple estimating techniques, hours and story points.  In this post, I am not going to tackle what I would define as advanced estimating techniques. I’m just going to limit it to the two below.

Technique 1: Hours

OK, who here hasn’t estimated in hours?  Though this doesn’t necessarily translate to zombies, it does to software development and other project activities.  Break efforts down in the smallest group possible, like tasks or user stories.  This technique is good but I think you need to really have a grasp of what you’re up against in order for it to be effective.  If you provide an estimate on an Epic or WBS Level 1 item, it loses its effectiveness.  Try to decompose (not like zombie decompose) work if it exceeds 8 hours.  The more time that elapses on a given task, the higher the probability something is going to change.  Get it completed and delivered so you can base your next estimation on something you’ve already done.

Please don’t estimate for other people.  Only provide estimates on things you’re going to do.

Technique 2: Story Points

Rather than estimating in hours, story points help people get past the uncomfortable feeling of saying they’ll complete something in X hours.  Sure, a story point could equal 1 hour but it doesn’t have to.  Think of estimating work at a relative amount compared to other work.

Imagine  two groups of the undead are lumbering toward you.  I’ll say group one is worth 8 points in size and complexity.  It takes you 20 rounds of ammo to take them out.  Though you didn’t get a head count, you’ll say the second group is 13 points in size and complexity.  If you only have 20 rounds of ammo left, how does that make you feel right now?  Do you run like hell in the opposite direction or do you think you learned something in the last round?

Once again, please don’t estimate for other people.  Only provide estimates on zombies you’re going to shoot.

Are you starting to see the parallels?

Like the image?  Find it at Pictofigo

5 Replies to “Zombie Estimating Techniques”

  1. The ‘zombie’ analogy is ‘killer’, no pun intended. Great rule of thumb: “Only provide estimates on things I am going to do”. Too often, Scrum Masters, Project Leads, Project Managers, etc. assume and report estimates based on their so called “gut feeling”, which actually comes from getting beat up by their superiors/project sponsors who pressure them into convincing those that actually do the work that it will not take as long as they say it will. Bad practice.

    1. Michael, I’m glad you liked the my zombie analogy.
      The team is agreeing to complete the body of work in the Sprint (or iteration), not the managers. If the managers are such accurate prognosticators, why even go through the exercise of asking the team for estimates? Because the manager’s estimating abilities suck! Let the team do their jobs. Let them use their expert opinions to provide the estimates. As far as I’m concerned, if you agree to the estimate provided by the team, you have a much more binding contract than if you tell them how long it will take.

Leave a Reply

Your email address will not be published. Required fields are marked *