What’s a good way to establish a Story Point Scale?

Here is what I generally coach:
(I assume that you have the pseudo fibonacci numbers that come with standard story point cards:  1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100)
1.  Try to imagine the smallest actual story (something that provides user/stakeholder value — an actual tiny feature).  Sometimes that could be just a configuration change, or  small change in the GUI.  Either give that a single point or a 1/2 point.  That’s your lower bound.
2.  Now, to be able to properly indicate a rough upper bound, I tell teams this upper bound will be the rough equivalent of the maximum story size — that is, the biggest story that a developer (or pair if you’re always pair programming) could do on her own in one iteration.  I usually tell teams to pick 8, 13, or 20 for the upper bound number so that we leave a few numbers that can be used for Release Planning and epics (= story too big to fit into a sprint).
3.  You now have a range starting with .5 or 1, and ending with something like 13.
4.  Look at a bunch of stories in the upcoming backlog, and size them in your range, remembering the smallest lower bound story you could imagine, and the upper bound story that could be finished(totally done) in one iteration.
This Agile estimation technique documented by Brad Swanson might help:  http://properosolutions.com/wp-content/uploads/2010/05/agile_estimation_2.0-for-pdf.pdf
5.  From here on out, size all stories relative to the first stories you sized as well as your upper and lower bound.
6.  Do this for 3 iterations, then retrospect and decide if you need to adjust your scales somehow.  Adjust only if the team feels a big need to.  Just be sure, if you do adjust your scale, to do so for ALL of the stories that you have previously sized(those that were in previous iterations, as well as the entire backlog that has already been sized).   If the team chooses to do this adjustment, it is only done once, and never again.  Sometimes teams new to Story Points want to spend too much time estimating.  In those cases, I’ve found that it helps settle the team’s nerves when they know they’ll have the opportunity to do this one time adjustment after the 3rd iteration.
7.  Go forth and prosper!

© 2010, 2011 Charles Bradley.  All Rights Reserved.

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I.  In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices.   He is Sun Certified in Java, and has  13 years of experience in J2EE application development across all tiers.  More recently he has also picked up some good C# experience as well.  In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests.  He lives in Denver, Colorado, and he is easily found on LinkedIn.