Sunday, May 15, 2011

White Elephant Sizing Game

I went to a informal Open Spaces-type conference yesterday.  It was my first time at this sort of self-organizing conference.  I had a great time discussing common issues and finding common solutions with a bunch of sharp folks.  One of the topics for the conference was a demonstration of a sizing estimation game called the "White Elephant Method".  It is an alternative to the Planning Poker estimation game.

Like planning poker, the goal of the white elephant game is to get a quick estimate of the size of an agile project and the size of the individual stories before the project starts.  The white elephant game attempts to do this in a way that can be reliably fit into a given amount of time and keeps the focus on getting the overall estimation done rather than disagreements on the sizing of particular stories.

Overview
The name "White Elephant" comes from the group gift-exchange game, also known as Yankee Swap.  In place of gifts, the team has stories.

Each team member takes a turn.  A team member is allowed a set amount of time to complete their turn, normally 30 to 60 seconds.  During their turn, the team member may:

  • Get a new story from the product owner and place it in an estimation category
  • Move an already-placed story to a different estimation category
  • Pass, if all the stories are placed and they are satisfied with the story placement
They may ask the product owners questions but should not discuss the items with their other teammates.

The game ends when all the stories are in a sized estimation category and everyone on the team passes.

The game's duration is easy to timebox.  A rough formula is 2 x turn-duration x number of stories.  If you have a turn duration of one (1) minute and thirty stories to estimate, you should be able to get a sizing estimate for all the stories in an hour.  Some stories will take almost no time to estimate.  Other stories or high-priority epics require more questions or interaction.  Overall, they should balance each other out.

Components
In order to play the White Elephant sizing estimation game, you need:

  • A product owner
  • A scrum master
  • A team
  • A stop watch
  • A story card for each story in the project
  • A set of category labels including:
    • Size estimates (1, 2, 5, 8, 13, 20, 40, 100)
    • Uncertain (?)
  • A place that can display the category labels and the estimated stories as they are added.

Preparation

  • Post the category labels around the area in a logical order so the whole team can see the category labels and all placed stories
  • Get story cards for each story.  Put them in random order.  Be sure to note the priority of each story on the card so it is not lost when the stories are reordered

Play the Game
The product owner, or scrum master, gives the first story to the first player.  Be sure to remind the player of the time limit.  The sizing categories are relative, so any placement is the correct placement.

Move to each subsequent player in turn, offering a chance to place another story or move an existing story.

If a story bounces back and forth between two categories, it is in contention.  Here are some ways to deal with contention:

  • Remove the story under contention and place it on the bottom of the deck
  • Move and lock the story into the larger of the two categories

A story may be too large to estimate or its estimate may be too large to work on in a single sprint.  As normal practice, decompose the story into smaller stories, add them to the story deck, and continue the game.

Players will have a tendency to break the rule around talking amongst themselves.  If the talking is leading to contention and arguments or is consuming too much, the team can remind them of the no-talking rule.  Otherwise, the talking is probably not a big deal.


Analysis
The White Elephant estimation game should help the team estimate stories faster.  It should also help the team feel more confident in completing their estimation work in a set period of time.

Introducing one story at a time helps limit the amount of uncertainty.  The first player does not have to consider everything; he only has to consider one story.  The complexity builds as more stories are added but the prior players' work help build "scaffolding" that helps the current player make their decision.

The no talking rule helps keep the interactions focused on product owner and team rather than a intra-team focus.  It seems that the product owner/team member conversation is the more important during estimation exercises.

No comments:

Post a Comment