If you ask an ordinary person about poker, you’ll hear that it is a card game that based on the ability to think many moves ahead, stay focused, and bluff in a convincing way. But actually, we can use poker in an office, for example, in a software developing and testing company.

Concept of Planning Poker

Planning poker (or scrum poker) is a special method involving peer review and further problem solution that appears during software development and testing.

Any specialists can participate in this procedure: programmers, testers, technical engineers, project managers, system administrators, designers, and other people who are involved in this project.

Since different members of the project team take part in this process, such a method allows obtaining a complex independent estimation when solving difficult technical and practical tasks.

By the way, this method was firstly described in the well-known Agile Manifesto by James Grenning. The name “planning poker” comes from Mike Cohn who let use his brand name for free in 2005.

Ideas of Planning Poker

The objective of planning poker is not only to set a task deadline but also [highlight dark=”no”]to ensure that everyone who participates in software development understands all the used algorithms and solutions.[/highlight]

Nowadays, a lot of global organizations and group companies use this method. Among such companies, we can distinguish the most famous ones like Coca-Cola, General Electric, KIA, and many others.

The Rules of the Planning Poker

This poker is carried out during meetings before beginning work on the project or when new functionality is deployed to the pre-developed product.

Every participant receives a special pack of cards. There are 2 most popular packs of cards.

The first variant

The cards based on a specialized rating scale by Mike Cohn. By the way, these cards build on the Fibonacci sequence (numbers 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 + card with “?” sign + card with the picture of coffee + card with infinity sign).

Interpretation of the cards

0	A task that is already done or a very simple task, hence it shouldn’t be in general workplan
1-3	Small tasks
5-13	Tasks with medium-level priority
21-55	Large and complex tasks
89	Global tasks
Infinity sign	The task is so large that it doesn’t make sense to give it some number
?	It gives additional information from the product owner. Some players can use this card to refuse to estimate the current sprint (but they cannot refuse to participate in discussion and estimation).
Card with the picture of coffee	It means that some player wants to take a break for some coffee or tea.

The second variant

These cards are based on numbers in the second power: : 0, ½, 1, 2, 4, 8, 16, 32, 64, 128, “?”, “cup of coffee”, infinity sign.

Roles

A scrum master is a moderator who chairs the gameplay. He/she monitors compliance with the rules, resolves the conflicts, keeps players away from potential distractions. The scrum master doesn’t play but records the results of the discussions.

A product owner represents the client’s requirements and wishes, as well as use cases. During the meeting, he/she reads participants all the requirements for the future product. Except for this, the product owner can act for end-users of the developed product.

If there is no product owner, then a scrum master or project manager can read the requirements.

Procedure

Before starting the game, the project team has to determine the numerical reference of the cards. It can be hours, days, or relative value of task complexity.

Also, the scrum master can use a timer if needed. It will help to save time on discussion and provide qualitative brainstorming.

At the beginning of the game, scrum master announces a task for discussion (or several tasks). Participants discuss it and ask the product owner (who is responsible for software) for some additional information.

After this, every player covertly chooses a card that meets his/her evaluation and lays this card face down.

As soon as all the participants define their estimation, players show their cards.

Game Results

• If the estimates are the same, then the compromise was reached and the agreed number is interpreted as discussed task evaluation.
• If there is a big difference among the estimates, the scrum master should pick those participants who gave the highest and the lowest estimation.
  These people speak to others and explain their choice in detail.
• All the participants proceed with discussion in order to dispel all doubts and suggest their guesses and solutions.
• Once the discussion is concluded, there is one more round of estimation. The game lasts as long as the team finds a common (positive) denominator.

Example of Planning Poker

Let’s imagine such a situation. A team lead gives developers and testers a deck of cards with numbers. They should discuss time expenditures for creating a mobile design of the website.

All the participants speculate for a while, then they take some card with a number and lay it face down. Thereby, no one can mislead those who haven’t made their choice yet.

So, the first players took the cards with 5 and 8. They should discuss the task with that person who took the card with 20.

One of the participants didn’t think through and took the card with the question mark.

After a short discussion, the third participant remembered that he/she hadn’t kept in mind some things and now wants to go back on the decision.

The fourth participant has fully gone into the matter and is ready to take an active part in general discussion. The cards are placed once again.

Every team member shows his/her card. There are the following values: 8, 8, 10, and 12.

As a result, the decision is taken and the team can proceed with the next case. This procedure lasts as long as all the actual questions will be fully and comprehensively considered.

Common Problems With This Method

1. The most urgent problem is the anchoring effect. Main error that causes this situation is an open discussion of estimates.
   For example, the first one who starts the discussion says the following: “I think that it takes about 20 hours to develop and test this feature”. And this can cause differing points of view.
   Those who thought that it would take 3 days to solve the task, will believe that 20 hours is enough. And those who planned to spend 5 hours, will think that he/she underestimate future functionality.
2. Another problem is nonsimultaneous estimating. In this case, someone can express his/her opinion, and someone puts the card closer to the rest.
   For example, one thinks that it takes 20 hours to solve the task. But three participants have already given cards with 6. It is logical to assume that such a person would probably think that he/she estimates the time for development incorrectly. He/she doesn’t want to stand out and change one’s initial decision.

When Should You Use the Planning Poker Method?

Similar scenarios for solving technical and practical problems should be used in the following cases:

• When working on small and medium projects (when no more than 10 people are involved in the software development and testing process);
• For projects with a flexible development methodology;
• For project teams with a very high level of communication and involvement in the software development/testing process;
• In companies that can spend enough time to fully resolve occurring issues.

In Conclusion

So, the basic advantage of using planning poker is the absolute interactivity of this technique, as well as its obvious ability to rally all the participants of the development process behind the resolution of the task. Thus, within a certain software testing company, the decision is taken collectively rather than personally.

A mandatory attribute of the qualitative organization of planning poker is the use of evaluative judgments. This allows the development and test team to take into account previous achievements and mistakes.

As a result, customers receive the correct estimates of the time and budget for the project. This is ensured by the fact that all the dedicated specialists who involved in the process of creating and testing a web product make a final decision.