Estimating the product backlog items - why using a relative scale

Why do you estimate? I see two big reasons, which are connected:

• You want to build the most business value for the least resources. Therefor you need to know how big stuff is so you know if it's worth it.
• You want to know when new or improved features can be put into production. This so sales people can sell them at the right time and the users to prepare (for example education, integrations and installations need to be planned).

If I were asked how long it takes to build a house of cards I can give you an estimate I could give you one in a second. And so can most people who know what a house of cards is. But if you have a room of 30 persons, you will probably get very different answers from most of the people. Some of the differences lies in:

• Perception of what a house of cards means. It could be two cards or it could be a deck of cards.
  
• Skill in creating houses of cards. Some people are good or skilled at it. Some are not.
  
• Difference in how you measure time. Is it an empty room, no one around and you get to work by yourself? Or what. This gives huge impact on the estimate.
  
• Tools available. If you're allowed to use glue or cards appropriate for building houses of cards you would probably give an other estimate than if you were using some old weak deck.

The list goes on and on with all those little things which affects how we give estimates. So, what can you do? One solution is getting better information. You specify exactly what you want and what the pre requisives are. What is wrong with this approach: well it takes too much time and it makes changes impossible. If you make one small change, well then the estimation falls. The only way to make a good estimation using this approach is building the house and afterwords saying how much time it took.

So, what can you do? Well, what you can do is look at two rough sketches of a house of cards and then ask: which one will take the longest to build? Do you think that it takes double the time or tripple the time?

It is probably hard to say it's 1,3 times harder so you need a scale which you can discuss from. A popular scale is 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100. And of course the higher the scale, the more insecure is the estimate.

Estimating using planning poker is fun, fast and amazingly accurate. I will not take trouble trying to explain it, because the Swedish consultant firm Crisp explains it much better on their web site. There you can also buy decks of cards (even if I love the Mountain Goat Cards). What I do miss on their page is the use of a Golden List. The Golden List is an example list of estimations. You identify a story of each size. By doing so you can ask questions like "well is it really twice as big as X". The Golden List should be made up by stories which you've finished but if you're starting up you can fake a list from previous projects or simply things people can relate to. Print the Golden List on a big sheet of paper and keep it visual during the estimation session. Break when discussions are going into hours and days: keep comparing!

But hey, this only answers one of my needs: the possibility to compare size to validaing we get the most business value for the least time. How do I know when things are released?