Set of reference stories

From Pearl Language
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

…multiple development teams working on a single product.

✣  ✣  ✣

Planning with predictability and sustainability creates trust and competitive advantage in the market.

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:

Bring a broad group of individuals representing various development teams together; e.g. pairs of each development team. Have them estimate a dozen or so product backlog items (ideally in the form of real user stories); it will take some more time to reach consensus with a large group; e.g. two hours to estimate 12 items. Have each pair of estimators take back to their development teams the two handfuls of estimates and use them as a comparing reference for local estimates. Publish a set of agreed-upon user stories and their relative estimates.

✣  ✣  ✣

  • 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