Mike Cohn suggests having workshop and estimating 2 dozen stories. I was thinking of adapting this idea for one team. The objective is to get the team agreeing/understanding about what 1, 2, 3 and 5 story points means to them:
Does anyone have any better suggestions for running this workshop?
To preface: the meaning of story points and velocity will evolve over time. They're a context-sensitive planning tool, and they can mean whatever the team needs them to mean.
For your question: more than the meaning of any one of those numbers, it's really about what is likely to take longer to deliver than what else. You might want to shift focus away from agreeing on numbers, to achieving a common relative understanding of the size of items you have recently completed and are about to work on. To rubberduck's point, the "swimlane" visualization technique can be useful for this: e.g. http://theagilepirate.net/archives/109
Often you won't have the luxury of taking a reference story in your first sprint or you're walking into a "team" that already is mid project and just starting to learn how to use scrum.
In these scenarios I often take this approach:
During a team retro or workshop ask:
What is the story point the team can agree to use to indicate a piece of work is the least complex or easiest thing possible to get done in a sprint? (Usually is 1pt or 0.5 pts)
What is the story point value the team can agree to use to indicate whether a piece of work is the most complex thing they feel comfortable getting done in the sprint (regardless of how many people are working on it)? (Often is a 13 or 21 for Fibonacci teams).
All shared understanding of values in between the min and max story points then evolve over time when you teach team members to start making relative comparisons each time they estimate. The value of story points is actually in starting the conversation about WHAT makes one story relatively more or less complex than another. This is how you spread information across team members so they start thinking about what it takes to comprehensively get a story DONE.
Defining the upper limit, while not super useful, will at least give the team a tool to say "this is way too complex, we need to break it down." Or, "This is really complex, maybe we should break it down because often we end up not getting this done in the sprint."
If you have existing data you can also can use statistics to identify what size of story the team starts to fail on. Does the team consistently carry-over 13 point stories? Maybe they should agree that 8pts is their cut off and anything over should be decomposed to an understandable level.
Story points are a form of relative complexity estimation.
"So we just agreed to call this story 5 pts, is the story we are estimating now relatively more or less complex than that 5 point story? What makes you say that?"
You can't force a team to develop a shared understanding of story points; the shared understanding develops naturally over time as the team learns how to work together. Story point understanding also naturally shifts over time as the team becomes more productive. The key to getting value out of story points is to apply consistent practices; not defining what each value means.
