For many people, the mention of poker evokes associations with a game in which the abilities to predict the situation in advance, to concentrate and to bluff perfectly are valued. Besides gambling, poker can also be used for planning work.
Planning Poker, Scrum Poker – is a flexible technique that allows, on the basis of collegiality, to clearly assess the complexity and scope of tasks to be solved during the creation of a software product. At the same time, everyone is involved in the assessment: programmers, a team of testers, database engineers, analysts, designers and all other employees involved in projects. Since these team members are very diverse, this approach allows for a truly versatile and, in fact, objective assessment.
Planning Poker – is an essential planning tool in Agile development. The approach was first described in 2002 by James Grenning, co-author of the famous Agile Manifesto. In 2005, the technique became part of Mike Cohn’s work in the book «Agile Estimating and Planning», gaining popularity among fans of Scrum (sometimes it is even called Scrum poker). Mike Cohn also owns the Planning Poker trademark and is giving away trademark rights and printing his own decks of cards free of charge.
The goal of Scrum Poker – is to set a deadline for an assignment, taking into account the opinions of each member of the product development team, avoiding the cognitive bias of anchoring. For example, when discussing the timing of the development and implementation of some functionality, one of the team members who has authority in the group is the first to name the number - it will take 50 days to complete the task, thereby setting a framework for thinking for the rest of the participants. The number 50 will be the starting point for each team member. Those who wanted to name the number 10 will want to overestimate it, and those who wanted to say 100 will, on the contrary, underestimate it. Planning poker identifies a potentially influential team member by isolating his or her opinion from other team members so they are not subject to the anchoring effect. This is accomplished by thinking independently and requiring that all participants show their cards at the same time.
One of the arguments in favor of introducing Poker planning rules in a team can be companies in which this method has already been adopted: General Electric, Cisco, Adobe, Amazon, The NCR Orderman, Wells Fargo Bank, NA, The Home Depot, IBM, Coca-Cola, Tesla, etc.
Planning Poker (Scrum Poker) rules
Planning Poker (Scrum poker) is held at a meeting before the start of software development or a development of a new feature of existing software.
Each member of the Scrum Team receives a deck of cards. The Scrum Team is a cross-functional team consisting of specialists of various profiles: testers, architects, analysts, programmers, etc., who work on the product from beginning to end. In a team, everyone helps each other, and everyone is responsible for the result together. Large teams are divided into several teams, each of which has from three to nine people.
There are two most popular decks of cards for Planning Poker:
1. The most commonly used rating scale proposed by Mike Cohn and is based on a modified series of Fibonacci numbers: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, a card with a question mark — «?», a card with the image of a cup of coffee, a card with the sign of infinity «∞». In this case, numbers can serve a designation for hours, days, etc.
The values of poker cards
| Card | Description
|
| 0 | This card indicates a task that has already been completed or is so small that it does not make sense to allocate space in the plan. |
| 1 - 3 | Serve to indicate the size of small tasks. |
| 5 - 13 | Serve to indicate the size of medium tasks. For many teams, task size 13 turns out to be the largest of those planned in the sprint (the amount of time it takes a Scrum team to create a part of the product that is ready to be shown and valuable to the customer). Therefore, they break an item greater than 13 into a series of small tasks. |
| 21 - 55 | Serve to indicate the size of large tasks. |
| 89 | Serves to indicate the size of the global task. |
|
∞ |
Serve to indicate a task of such a large size, it does not even make sense to assign a number to it. |
| ? (question mark) |
This card asks the Product owner for further clarification. Some team members use this card to opt out of rating the current item, usually because they are so distant from it that they have no idea how to rate it. If it is still allowed to refuse the assessment, then it is impossible to refuse to participate in the assessment. So, if someone does not consider it possible for themselves to give an assessment, it does not give them the right to shy away from discussion or responsibility for helping the team come to agreement on the assessments. |
 |
This card serves to indicate the need, according to the team member, to take a break for a cup of tea or coffee (possibly with a sandwich). |
2. The alternative scale used by the teams is based on a series of numbers to the 2 power: 0, ½, 1, 2, 4, 8, 16, 32, 64, 128, «?», «Cup of Coffee», infinity «∞».
The Scrum Master acts as the host of the game, ensures that all Scrum principles are adhered to, resolves conflicts, and protects the team from distractions. The Scrum Master does not participate in the game itself, but documents the results of the discussion.
The Product Owner – fulfills the role of the «source» of functions/requirements/user scenarios. During the meeting, they read out to the participants all the requirements for the future product, The Product Owner represents the interests of end users and stakeholders in the product.
In the absence of the product owner, both the scrum master and the project manager can read out the requirements at the meeting.
Before starting the game, the team must determine the numerical advantages of the cards. These can be hours / days to complete the task or relative units of difficulty.
If necessary, the presenter can use a timer during the meeting. This will help the team not to drag out the discussion of one function for several hours and provide a brainstorming session.
The host announces one of the tasks. Team members discuss tasks and ask clarifying questions to the product owner, and he or she answers them.
Then each participant (evaluates) secretly chooses his card that corresponds to his assessment and puts the card face down.
As soon as everyone has decided on the assessment, the participants simultaneously show their cards, denoting their personal assessments.
- If the estimates of the declared task are approximately the same for everyone, this means that mutual understanding has been reached, and the agreed number becomes the assessment of this task.
- If there is a big difference between the given estimates, then the host chooses those participants who put the minimum and the maximum number.
- Each of them must speak to the team and give reasons for their choice. Team members begin the discussion to identify any misunderstandings and voice their suggestions.
- After discussion, another round of evaluation is conducted and the procedure is repeated until there is general consensus.
Let us take a look at a simple example:
The Scrum master distributes a deck of cards to each participant and the Product owner brings the question up for discussion. For example:
– How many hours do you think the website design development will take?
After thinking, each participant takes a card and puts it on the table face down. When everyone has put their card, the cards are revealed.
The first two participants gave approximately the same «5» and «8» rating, now they need to discuss this with the third participant who chose «20».
The latter does not understand the topic at all, so they chose «?».
After a short discussion, the third participant recalls that he did not take into account some points and is ready to reconsider their decision.
The fourth figured out the issue, now they are also ready to participate. The cards are laid out. And revealed again!
– We can proceed to the next task.
The main mistakes in Planning Poker
- The main problem that Planning Poker solves is the cognitive anchoring bias — in simpler words, anchoring effect, which can manifest itself in different ways. The main action causing this effect is open discussion of estimates. If the person who starts the discussion says something like the following: «I believe that this task will take 18 hours of development», then one way or another, everyone will be focused on 18 hours, and those who thought that the task will be solved in 2 days may think that in fact even 18 hours will be enough, and those who thought about 5 hours might think that they underestimated. On the one hand, consensus is achieved faster, but on the other hand, it will not be effective, and efficiency is what it is being done for. In such a situation, the result will include the opinion of the person, rather than the opinion of each team member.
- The situation when the assessments are not given at the same time can become a problem. In such a case, someone will simply express their opinion, but on the other hand, a person throws out a card that is estimately closer to the ones that are revealed. For example, someone decided that the task would take 18 hours, and two participants threw out 5 hours to that participant. And it is logical to assume that this person will quickly react to what they assessed wrongly, and so it is not worth standing out and will throw out not the card they wanted originally.
It is advisable to use the Poker Planning method in the following cases:
- for small and medium-sized projects (with appropriate teams, no more than 10 people);
- for projects with an agile development methodology;
- for teams that already have a high level of communication and engagement (or teams that really want to achieve this and are willing to put in the effort);
- for teams and tasks where there is an opportunity to spend time building consensus.
Thus, the undoubted advantage of poker planning is the interactivity of this technique and its ability to unite the team, making it so that the decision is not made by anyone alone, and then it turns out to be ineffective, but because during the planning, everyone expresses their opinion independently of the others.
An essential element of well-organized poker planning is the use of data from previous assessments, which allows the participants to build on mistakes and achievements that have occured in the past. Customers receive the most accurate estimates of the timing and budget, because all the necessary specialists are involved in their formulation.
In addition, this planning method is interesting and exciting due to the usage of cards.
