Jochen Krebs Jochen Krebs Jochen Krebs Jochen Krebs "Making tradition means breaking tradition."-Jochen Krebs
Home | Publications | Training | Speaking | About Me | Contact 07/30/2010 © Jochen Krebs


User Story Sizing Game

by Jochen Krebs
Version 0.9 April 2009
Check Jochen Krebs for updates and further material.

What is the Sizing Game?
The Sizing Game is a quick, easy and playful way to categorize user stories in an agile project based on relative size. Although the game material is intended for educational purposes, the game maps directly to any real project environment. You can even play with your own specific user stories instead of the example stories.
The Sizing Game can also compliment or be part of other agile training exercises which require story sizing, for example backlog grooming, planning and estimation.

Participants will learn by doing to:
  • Group user stories according to their relative size/effort.
  • Reach a democratic consensus quickly.
  • Maintain consistency in estimation across iterations.
  • Learn how user stories are captured.
  • Reach consensus results without discussions.
  • Actively collaborate and have fun.
Although the first two of the three iterations will cover the learning goals, it is recommended to execute the third iteration as well. This additional step will reinforce learning goals and show how the sizing process itself will become more efficient.

Rules
The exercise works best in groups (project teams) with 4-6 players or more. Building smaller teams in the classroom setting will have a positive impact on the learning goals, because with every round of the game, players take turns more frequently which adds to their learning experience. Therefore, if you have 5, 10 or 15 students, group them into 1, 2 or 3 teams respectively and have the teams stand-up in a half circle facing the sizing board.

As the instructor/moderator of the game, explain the game rules to the participants. Take the prepared story cards (one deck for each team) for the first iteration, shuffle them and place them face down on a table in front of whiteboard. Place the timer next to pile of cards.

The game begins when the facilitator starts the timer, which is the signal for the first player to pick the top most card from the pile. Within the minute, every player performs the following steps:
  • attaches a piece of masking tape to the card
  • reads the story on the card out loud
  • assigns the card to one of the five columns on the whiteboard
  • provides a reason to the group
  • starts the timer for the next player again.
Let’s take a closer look at the individual steps listed above. First and foremost, explain to each group to remember the playing order, because you want everyone be equally involved. The masking tape is very practical, because it will allow the moving of cards easily on the board without damaging the surface or story card.

It is important to explain that assigning the card to one of the five columns has to be the player’s own decision, without any external interference. That is why the player should provide the reason for her decision after the card has been assigned. If the player does not assign the card within the one minute, the card will be assigned to the column in the middle. The player then will restart the timer for the next player.

The columns on the board represent the size of the user story. The column on the far left stands for the littlest effort, whereas the one on the right would mean the highest effort. The player’s reason may be her own expert knowledge from past experiences or observations from other projects. For example “because I remember xyz was quite an effort” or “because a friend of mine recently told me about the effort of xyz”. Although the player which assigns the user story is the most active person in the game, it is essential that the rest of the team observes and listens carefully to understand the overall context and development of the board. All passive team members are therefore silent without discussions or judging.

For a group of 4-6 players continue taking cards from the pile for at least two rounds to get enough cards on the board. Then, at the top of the order, you give every player the option to continue taking cards from the pile like before, or move an existing card on the board into a different column. In both situations, the player continues reading out the story followed by a reason which supports that decision. At each turn, every player can only assign a card from the set OR move an already assigned card; not both. Once user story cards are all at the wall and the pile of card is gone, every player can either continue moving cards on the board or simply “pass” if they are satisfied with the current result on the board. If a player can not make a decision within the one-minute time-limit it will automatically translate into a “pass”. The game is over when the pile of story cards is gone and all players signal “pass”.

In an educational session, your teams will play two or three games, to simulate iterative-incremental development and to learn how additional user stories are consistently sized.

After the first game, the moderator takes a picture, captures the sizing results on a separate sheet. She then removes all cards and puts them aside. One of the cards, “Story Card #3”, is assumed as a “typical” medium. In a real project, that reference card may be a team agreement as a result of a retrospective. That card is placed on top of the third column (medium size). The moderator takes the story cards for iteration 2, and asks the players to have every decision relate to the reference story on top of the middle column. The reference story can not be moved or adjusted. Complete iteration 2 and continue with iteration 3 in the same fashion. In the last iterations, story card #3 will be used as reference story.

Challenges
The biggest challenge in the first iteration is the missing reference story. Because no card has been assigned yet, the first player will lack a comparison. That is ok and actually an important lesson of the game. Because the facilitator will shuffle the cards prior to the start of the game, we won’t know if the first stories are really small, medium or large until we uncover more. That is ok, and every player will have the opportunity to change their mind in upcoming rounds. Remember, the game does not stop until all players signal “pass” to the facilitator.

It is quite typical that two or more players disagree about a few assignments, and the card moves forward and backward on the board endlessly. Take the card and place it on the bottom of the deck. That way, the sizing can continue, and the card will have more about the context when all other cards are already on the board.

Tips and Advice
In a classroom, have all students part of the exercise and the instructor should play the facilitator. In a real Scrum project, the Scrum Master will facilitate the exercise.

Make sure the players understand that the outcome of the game is a project result. They speak-up, assign and move cards during the game or wait until the next session.

In a real project, an acting product owner should by-stand this exercise to answer questions and clarify requirements on the card. That way the players learn more about the context of the requirement.

Preparation
For each group, you will need:
  • Timer (to give every participant 1 minute to make a decision)
  • One set of iteration-1 stories
  • One set of iteration-2 stories
  • One set of iteration-3 stories
  • Masking tape pieces at the edge of a table
  • Whiteboard, flipchart or cling sheets.
I will soon release a set of example user stores.

Variations
  • Play with 3 (S,M.L) columns instead of 5 (XS, S, M, L. XL)
  • Begin with 3 columns until the team requests more granularity, then the moderator adds additional columns.
  • Play with your own project user story cards
  • Assign the Fibonacci sequence to the columns (1,2,3,5,8) instead of T-shirt sizes.