No matter what point scale you use to estimate stories, and if you call them “points”, “gummi bears”, or “t-shirts”, people always want to know what they mean. The problem is that the keepers of the points don’t know how to relate to the users of the points.

Joe: “Oh look a new story in the icebox!”
Sam: “Let’s estimate it!”
Joe: “Sure, what’s a ‘one’ work out to be in terms of effort/complexity?”
Sam: “That’s like… half a day”

I’ve been in Joe’s shoes, and I’ve been Sam too many times. Do you see the disjoint? Hint: check the bold. Joe asked about effort/complexity because those are things he can estimate with some degree of accuracy. Sam jumped to the lowest common denominator, and converted his concept of a one point story into a unit of time.

Problem: Velocity is the conversion factor from points to time. Velocity is useful, Sam is not (no offense if your name is Sam).

A “one” is what then? It varies from team to team. How do I get Joe up to speed on point values then? Common ground, relate to Joe. We’ve all done some programming before. Maybe a one is “a batch of CSS changes”, and two points works out to “administrators should be able to edit all product fields”. Then you work your way up to “make a web-based zoo” which is wherever your point system tops out because it has a lot of unknowns and/or complexity.

Relation Points, use them to relate to your fellow developers. Use them to relate to your product owners and managers. Start speaking in terms that show you’ve got more knowledge about the development cycle than a random guy off the street. Anyone can give you the time, but what you really want… is to get to the points.