Set of reference stories

…multiple development teams working on a single product.

✣  ✣  ✣

{{{wish full}}}

Mike Cohn:

• In a consulting firm I would absolutely want to strive to have a common baseline for story points.

Wish:

• establishing a common definition of a story point across multiple teams within an organization
  • helps estimation and planning in general and gives a common basis for capacity (given that teams, technology, processes and tools remain relatively stable);
  • clears up any confusion and suspicion of underachievement in the higher management layers;
  • allows consulting firms to create ‘SLAs’ based on empirical data rather than risky guesses;
  • may help to surface particularly bad environment/political issues on certain projects - “hey, why does it take 5 times as long to do a story point on this project?

Forces:

• some people strongly resist or reject estimation, let alone creating a common baseline for story points (e.g. orthodox Kanban adepts);
• teams can be unfairly compared to one another;
• estimating time (e.g. ideal days) is very dependent on individual skills and experience

Therefore:

{{{therefore full}}}

✣  ✣  ✣

• Using some artificial user stories as they’ll be more likely to be understandable by a broad set of consultants.
• Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to).

✣  ✣  ✣

Sources

• http://www.mountaingoatsoftware.com/blog/establishing-a-common-baseline-for-story-points

---