Poker Planning is a favorite technique of many people, including me. I like this technique of estimation because it lets us make estimates in relative terms. People are notoriously bad at absolute estimation of the “rank this item one to ten”, variety.
Have you ever looked at the website HotOrNot.com? It turns out that pretty much everyone from Quazzi Modo to Angelina Jolie ranks from a 4 to a 7. This is a prime example of our poor ability to estimate on a closely related value scale. It is pretty tough to tell if something is a 2 or a 3, but it is pretty easy to see the difference in size between a 5 and a 13. 13 is more than twice as big as 5, right?
Think about it this way: Does it really matter if something is going to take 3 hours or six hours? In software development, it typically doesn’t matter.
So the relative estimation model looks like this, in pursuing an estimate for piece of work A:
- Is this piece of work bigger or smaller than that piece of work B that we already did?
- Bigger? OK, how much bigger? 2X bigger? 3X?
- OK, 4X bigger.
- Here is piece of work C that we already did. It was estimated at 4X bigger than B. Is it roughly the same size as A?
- Yes.
- Cool, we are done.
Once we understand that we can trust these relative comparisons because we are better at them than empirical estimation, it becomes much easier to size our work. Look at things you’ve already done and estimate the new one in relation to the previous work. We get our relative size and convert it into time, dollars, or whatever the project managers need and we are done. This is a much faster (and accurate) thing to do than to break it down into tasks and estimate each task. Why? Because we will never get the tasking right.
There is a ton more that could be said (and has) on relative estimation, but remember this: The next time you have to estimate a project for your manager, make it easier on yourself by doing a relative size first. You’ll get back to coding much faster and you’ll find the numbers are amazingly accurate.