Create a Proper Estimate Scale...

Tuesday I pointed at Jim Schiel's article about using an abstracted story point scale instead of calendar time (days/hours) for estimation. This morning I read a new article by one of his colleague's at Danube about their issues with their current internal estimation scale.

So, the question is, how DO you come up with a good abstract scale? Here are the main points I believe you need to address when attacking this discussion -

• Atomic unit of measure - the unit of measure needs to be atomic. This means that a value of 2 needs to be 2 times bigger than the value of one. A ten is 10 times bigger than the value of one. Why? so that when you know your team's velocity equals 10 and you select a 1,2,3 and 5 point story for a sprint, you know they actually add up to a sum velocity of 10.
  
• Restrict allowable numeric selections - don't allow just any old number to be assigned to a story. Poker planning estimation decks can't contain every number between zero and one thousand, and you don't want it to. Human brains are very bad at estimating. The larger the estimate, the larger the error. It is easy to state that something will take 1 minute to do... it is very hard to state with confidence whether something will take 60 minutes vs. 62 minutes. The higher your number, the wider the gap between confident values. Most teams use a doubling sequence (1,2,4,8...) or a Fibonacci sequence (1,2,3,5,8,13...). When estimating, you are not allowed to pick a number that doesn't exist in the sequence. Why? it is a waste of time to watch your team bicker over the 12 vs. 13 estimate value on a story when their estimation error is larger than the delta between the two sides of the debate.
  
• Create non-numeric selections - not all estimates can be covered by a value on your scale. Most poker planning decks include a few others. Examples: Question Mark (I don't understand enough to estimate with confidence), Infinity (I understand but it will take longer than we will ever have), Coffee cup (If I don't get a bio. break first, then my estimate will be whatever you want it to be), Zero (it can be done quicker than it will take to have this conversation). Why? This facilitates the conversations that planning and estimation need to flush out. Remember that estimation is not just about predicting, but also about understanding and committing.
• Pick a reinforcing name - pick a metaphor that will invoke interest and understanding. Many people call them points, but some use more interesting terms. Examples: headaches (bigger is bad), donuts (reward I'll get for delivering), dings (times I hit a bell when I deploy), dukets, dolla, goats, bricks, cans of jolt, etc. Why? It not only engages a team, but can put focus on a positive (or negative) part of the process that needs to be used as motivation.
  
• Allow adaptability - remember, this is an abstract scale. It can be adjusted. If after two weeks you find yourself using decimals because you need units under one... then shift your scale. I've done this twice and found two good options. Add a zero (multiply by 10) so that people don't lose reference to the old scale and can transition with ease, or make up a new scale and spend an hour quickly re-estimating the whole backlog. Why? When people have to think about what a value means, then they are losing their ability to do comparative estimation.
  

Feel free to add your comments about other concerns that need to be covered.

Note: If you are interested in other posts about why to use story points, I've also posted about it myself here and here.