How to get team agreement about what story points mean to said team

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:

1. Look at a sample of stories which were voted as 1 point stories in the past and select one as the baseline for 1 point stories
2. Complete step 1 for 2,3 and 5 point stories.

Does anyone have any better suggestions for running this workshop?

• What is the problem you are trying to solve? Is there an issue with the team's estimating? Jan 30, 2017 at 22:04
• To get the team to have a common understanding of what 1, 2, 3, 5 means to the team. Jan 31, 2017 at 11:21
• I get that you want to establish a common understanding. I'm trying to understand what the problem is that you have as a result of a lack of common understanding. Do you have disagreements during estimating relating to story sizes? This would help me to better answer your question. Jan 31, 2017 at 18:27
• Swim lane sizing is a great way to calibrate a team's sizing. I'd leave an answer, but I'm too lazy to copy enough of that blog here so that it'd be more than a link only answer. +1 to whoever cares to... Feb 2, 2017 at 1:16

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

• Welcome to Agile, where the rules are made up and the points don't matter. +1 Mar 2, 2017 at 12:47
• Where the rules are context-sensitive & honest, and we own our planning Mar 2, 2017 at 13:40

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.