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.
Team Estimation Game – table of contents:
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.
We write about this technique in the previous article. Today, let’s focus on Team Estimation Game.
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:
- 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.
- 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.
- 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.
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.
If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing