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
Popularity: 1%
While reviewing proposal documentation yesterday, I noticed the contractor’s predicted velocity rate was pretty high. Being they are not experienced in using Agile and they haven’t even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration. I know how many developers they intend to use and I know their proposed iteration durations. I’m not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.). So, what did I expect?
Free PMI-ACP Exam
