Team Estimation Game is a technique facilitating Sprint Planning in Scrum. How does it differ from Planning Poker? Why do some Development Teams find it a more effective tool and others don’t? You’ll find everything you need to know about it in the following article.

#### Introduction

The Team Estimation Game is also called Swimlanes Estimation. The latter term originated as spontaneous observation of a card game as the display of cards resembled the swimming lanes of a water pool.

### Team Estimation Game is constantly gaining popularity, as it enables Development Teams to create estimates about 3 times faster than using Planning Poker.

#### Rules of Team Estimation Game

Team Estimation Game prompts:

• a deck of User Stories cards – prepared separately for each game
• a deck of Story Point cards – for repeated use

First, stack the User Stories cards in the order corresponding to the entries in the Product Backlog. To ensure the most urgent ones get estimated first.

The scoring cards usually contain values corresponding to the Fibonacci sequence. This is a sequence of the following numbers: 0, 1, 3, 5, 8, 13, 20, 40, and 100. You can also label them with successive powers of the number 2, that is, 2, 4, 8, 16, 32, and so on.

### The phases of Team Estimation game:

1. Introduction. To play the Team Estimation Game, the Scrum Team members sit around a table. Product Owner begins by drawing the first card from the User Story deck and sharing its content with all. Then, the cards stay on the table. Then Product Owner explains to the rest of the Scrum Team that from now on, players will evaluate User Stories as easy or hard to implement by placing them accordingly to the left and the right. If any happens to have some degree of difficulty, the player will stack together, one on top of the other on the table. Now, the person sitting next to them clockwise makes the next move.
2. A player draws a card from the User Story deck. After sharing its content with all, explains its essence to the Product Owner. The person holding the card then places it on the table and selects a seat based on their opinion o the difficulty of this User’s Story. Then, the player explains the rationale behind the choice to all and the other player are free to ask questions concerning the reasoning. They can’t question the decision itself but the arguments justifying the decision.
3. Now, players take a turn and have two options to choose from:
• Repeat step 2, or
• Move one of the cards on the table to its most appropriate position

If they go for the second option, they should also justify what made them change their mind. Players take turns repeating step 3 till there are all cards from the User Story deck get distributed and estimated.

4. The final stage of placing the User Story cards happens once, or many times, depending on Scrum Team practice. During this round, each player has yet another opportunity to move one of the cards on the table to a more appropriate place.
5. Once the players assign all the User Stories cards to their locations representing levels of difficulty, the Development Team moves on to match value by assigning the cards from the Story Point pile. The first User Story card on the left gets the Story Point card with the lowest number of points by the Product Owner. The rule for placing subsequent cards is the same as for points 3 and 4. This completes the estimation.

## Team Estimation Game versus Planning Poker

The Team Estimation Game is considered a more effective estimation tool than Planning Poker. Because of the following differences between these two techniques:

• Card-table. The Team Estimation game uses the well-known “card-table rule” from popular card games. This means that once you have placed a card, you cannot take it back. Because User Story gets estimated by one person at a time, the fluctuation between estimations and the number of times the shift positions is significantly lower, in comparison to Planning Poker.
• An accurate enough calculation. In Planning Poker, a full consensus should be reached for each User Story. In Team Estimation Game, however, only one person decides. Even if his/her estimation is wrong, another Developer will likely place it on matching its value more precisely. This way guarantees reaching a sufficiently accurate and quick estimates
• Exhausting the subject of discussion. Arguing choices often get excessively long when playing Planning Poker. Their time is greatly reduced during a Team Estimation Game because they focus on a single decision by one of the Developers rather than the nature of each User Story.

One potential drawback of the Team Estimation Game is a sense of unfairness. If the Development Team is larger than the number of User Stories scheduled in a given Sprint, some Developers may feel left out.

### Team Estimation Game – summary

Team Estimation Game has an opinion of the most effective estimation technique for most Scrum Teams. However, it is important to remember that it is only a tool for estimating the difficulty and effort of User Stories. And like any tool, we should adjust it to match the needs and capabilities of the Team members.