Establishing a Common Baseline for Story Points

A common criticism of story points is that the meaning of a story point will differ among teams. In this post I want to describe how can we establish a common definition of a story point across multiple teams within an organization.

The best way to estabish a common baseline for story points across teams is to bring a broad group of individuals representing various teams together and have them estimate a dozen or so product backlog items (ideally in the form of [user stories](/agile/user-stories)). Not every estimator needs to understand every item but most people should understand most items.

The items being estimated do not need to be new items:

  • Some could be from a project finished recently that many estimators remember or worked on.

  • Some items could be artificial; perhaps the team is asked to estimate, "a typical transaction activity report." If that meant something to most estimators, it would be a good candidate item.

I've done with this 46 people in a large conference room--44 estimators plus me and a coach from my client who wanted to watch so he could moderate such a meeting the next time one would be needed. The 44 estimators represented 22 teams; two estimators per team were in the meeting.

If you've seen or used a Mountain Goat Planning Poker deck, you'll have noticed that the cards feature a very large number in the middle (plus the number in a smaller font in the corners). We could have done something cute like put eight little goats on the eight card. We put the very large number there deliberately, though: We wanted it to be visible across a potentially large conference room.

You can probably imagine how difficult it might be to gain consensus among 46 people playing planning poker. While it will not take proportionately longer to derive estimates, it does take quite awhile with that many people. I think it took us about two hours to estimate twelve items. But when that meeting was over, each pair of estimators went back to their teams with twelve estimates. Those estimates could then be used as the basis for estimating future work. As each team estimated new product backlog items they would do so by comparing them to the initial 12 plus any estimates that had been produced since (by them or any other team).

To see if it is a good idea to establish a common baseline, read Is It a Good Idea to Establish a Common Baseline for Story Points?

Article artwork for The Best Way to Establish a Baseline When Playing Planning Poker.
Article

The Best Way to Establish a Baseline When Playing Planning Poker

Featured

Establish useful baselines so Planning Poker estimates stay relative.

Article artwork for How to Estimate Story Points With Multiple Teams.
Article

How to Estimate Story Points With Multiple Teams

Featured

Establishing a common baseline allows multiple teams to estimate consistently with story points.

Text graphic: Shared baselines can help or hurt across teams.
Article

Is It a Good Idea to Establish a Common Baseline for Story Points?

Featured

Decide whether shared story point baselines help or hurt across teams.

A Second Way to Prevent Estimate Inflation
Download

A Second Way to Prevent Estimate Inflation

Learn one more practical technique for preventing estimate inflation and keeping your team's story point estimates useful over time. Go beyond the blog post - find out one more way to prevent estimate inflation.

Article artwork for Four Reasons Agile Teams Estimate Product Backlog Items.
Article

Four Reasons Agile Teams Estimate Product Backlog Items

Estimating product backlog items provides benefits beyond predicting when a project will be finished.