The Agile Estimation Game


25 februari 2015

Enrise Agile Estimation Game

The Agile Estimation Game: Estimating Your Product Backlog in a Finger Snap

Many software developers are familiar with these everlasting estimation sessions where the entire product backlog is discussed and estimated story by story. This way of estimating the size of the product backlog is not only a torture for the people who attend, you should also question how much value this way of estimating delivers compared to the time and budget you spend in a conference room with the entire development team. Inspired by the team estimation game and the magic estimation game we started exploring a better way of estimating our product backlog. The result is what we called The Agile Estimation Game. With this blog post I would like to share how we do it, supported by a short movie that was captured during an agile estimation game session for one of our projects.

What you should know before you start

The goal of the agile estimation game is to balance the time spent on estimating with the value it delivers. It is important to know that it will not result in a better estimate. However, spending substantially more time on estimating the product backlog does not make that much of a difference. It is important to acknowledge that the estimate, which can be in story points, t-shirt sizes or even just the number of stories, is just an indication of the approximate size of the product backlog. This indication should be used as a tool to make the right strategic decisions instead of seeing it as an exact identification of the product backlog’s size.


First of all the development team needs to have at least a basic understanding of the product backlog. If this is not the case, give the Product Owner one hour to explain the product backlog as good as possible or give the team some time to study the product backlog individually.

You will need the following tools prepared for the session:

  • Printed or written index cards of all product backlog items, containing at least the title, but you may also include the type (epic, feature or story);
  • Cards with the possible estimates (ie. story points, t-shirt sizes);
  • A large open space to place the cards (can be a large table, wall or floor);
  • Tape.

Step 1: Prioritize the backlog from smallest to biggest

The goal of step 1 is to place all items on the used space, in our case a wall, where the item on the left is the smallest and the item on the right the biggest. These are the rules of engagement for this step:

  • All index cards of the product backlog items are placed in a deck;
  • Players take turns picking a card from the deck;
  • The player who picks the card reads the title of the index card out loud and places it somewhere on the wall;
  • Instead of picking a new index card from the deck, a player may also choose to move an existing index card on the wall;
  • During step 1 there is no discussion, only the product owner may give a very brief explanation in case it is totally unclear what a given item is about;
  • It is not allowed to place index cards on top, above or underneath others, they must be placed before, between or after the already placed index cards;
  • If the space is too small for all index cards to be placed from left to right, you can choose to make two rows, where the top right is biggest and bottom left smallest;
  • Step 1 continues until all index cards are placed on the wall.;

Step 2: Study and discuss

The goal of step 2 is to improve the order of the index cards that have been placed on the wall:

  • All players study the order of the index cards individually;
  • In case a player does not agree with the position of an index card, he places it slightly upwards, so that it is visible that this index card needs to be discussed;
  • After about 10 to 15 minutes the team starts discussing the cards that have been placed upwards;
  • After discussing an item the team may choose to move it to another spot on the wall;
  • During this step the product owner may take some more time to elaborate on the index cards that are being discussed so that they become more clear;
  • In case of a long discussion just place the index card to the largest suggested position;
  • This step ends when all index cards have been discussed and and the team agrees on the order from smallest to biggest.

Step 3: Add estimates

The goal of this step is to divide the index cards in estimate buckets. In our case we use story points based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55):

  • The team places the estimates on a place on the wall above one of the index cards, starting with the smallest estimate;
  • The index cards underneath and to the left of the estimate card are given the smallest estimate;
  • The same is done for all next estimate sizes, where all index cards underneath and to the left of the estimate get the corresponding number of story points until the previous estimate card is reached;
  • The team continues until the largest index card (the one to the most right spot of the wall) has the right estimate.

Step 4: Final check

The goal of the last step is to take 5 – 10 minutes to do a final check. In case of doubt, an index card can be discussed shortly for the last time and may be repositioned on the wall. Also the position of the estimation cards may be changed. Beware of too long discussions: the goal is to get a rough estimate of the entire size of the product backlog. In case an index card is being discussed too long, the scope is probably not clear enough and you might want to take the higher estimate so that the unclarity is encapsulated in the estimate. The team can refine the unclear items later on to remove the unclarity and re-estimate it.

Start estimating your product backlog faster right now

So, there are several approaches to decrease the time needed to estimate your product backlog. You may choose the team estimation game, magic estimation game or use our agile estimation game. With any of these approaches you will be able to speed up your estimation process enormously and I would strongly encourage you to do so. It will give you enough knowledge to create and adapt your product development strategy and still save you a lot of valuable time.