What is Planning Poker?
Planning Poker Definition
Planning Poker is a technique for teams, for the joint, playful estimation of expenses. As usual in a card game, each participant receives a set of numbered cards. After a task to be estimated is named, each player chooses the card with the number that corresponds to the effort required to complete the task. In order to avoid mutual interference, the selected cards are placed on the table face down, i.e. with the number facing down, and are revealed together on command. Then a discussion about the individually estimated effort begins with the aim of arriving at a common assessment. Planning Poker is therefore also considered a consensus-oriented estimation technique.
Planning Poker and the Agile Manifest
Planning Poker is a variant of the so-called Wideband Delphi method. It is often used as an alternative to the Team Estimation Game or Magic Estimation in agile software development. The method was first defined in 2002 by James Grenning, one of the authors of the Agile Manifesto. Planning Poker became popular in 2005 through Mike Cohn’s book “Agile Estimating and Planning”. Cohn was one of the founders of the Scrum Alliance and is now active at Mountain Goat Software.
Scrum Poker equals Planning Poker
Alternatively Planning Poker is also called Scrum Poker, but not because it has its origin in Scrum, but because it is used in Sprint Planning in Scrum. The list of tasks then corresponds to the Backlog or Sprint Backlog. Planning Poker is often played in Extreme Programming as well, but there is no such term as Extreme Programming Poker. Basically the use is always suitable when the complexity or the effort of individual tasks must be estimated and several employees contribute to a development together.
Planning Poker cards and their meaning
The Planning Poker card set consists of 52 cards. Each participant receives exactly 13 cards and each participant has exactly the same cards as everyone else. With one set of cards, four participants can estimate effort (52 : 13 = 4). If there are 5 participants, 65 cards are needed and thus a quarter of another card set.
Of the 13 cards, eleven cards show a numerical value. Most card sets use an adapted Fibonacci sequence – sometimes also called the Cohn scale – with the values 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. The numbers express that
- with increasing complexity and uncertainty, higher risk and the amount of work to be done, the accuracy of the estimate decreases. It is much easier to distinguish in an estimation whether an activity takes one or two days or 80 or 81 days.
- it is a matter of relative values. An estimation with 3 points should be three times as large as an estimation with one point.
Alternatively, there are card sets with a pure Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144) or the so-called T-Shirt Sizes (XS, S, M, L, XL, XXL). Usually the estimation is based on the Story Points that are widely used in Scrum.
In practice, the following understanding of numbers has proven to be useful:
- 0 means that a task has already been completed.
- 0.5 is a very small task.
- 1 to 5 are rather small tasks.
- 8 and 13 are medium tasks. 13 can well be chosen as maximum complexity for a task that can still be completed in a sprint.
20 and 40 are too large for a sprint and need to be made smaller for later rounds.
- 100 stands for a very large task such as an epic, which cannot be estimated at this stage and without further detail.
In addition to the eleven numbered cards there are two special cards:
- A card with a coffee cup to suggest a break.
- A card with a question mark, which is used when a participant is uncertain, wants to clarify contents together before the individual estimation or does not want to or cannot give an estimation.
Card sets are often sold online. Some providers also offer individual adaptations in design, colour and logo.
The Planning Poker process
For a Planning Poker, a moderator is required in addition to the participants and the cards. In many organisations the Scrum Master takes over this task. He determines a topic for the meeting, explains the procedure, names the tasks to be estimated and is available for questions. However, he himself does not play the planning poker.
The following procedure has proven itself:
- The moderator names the first task to be estimated and explains it if necessary.
- Each participant individually estimates the complexity of the task and places the card with the appropriate number face down on the table in front of him.
- All participants turn their cards over together on the moderator’s command. The individual estimates become visible.
- The participants with the highest and lowest estimates discuss your choice.
Afterwards there are two options:
- The participants with the highest and lowest estimates agree on a common value.
- There is another estimation round with all participants based on the new information.
The procedure from estimation – discussion – re-estimation could theoretically be repeated until a common effort estimation is reached. However, if no agreement is reached, the moderator should postpone the estimation of this task (to the end of the planning poker round or to a new date) and move on to the next task.
The advantages of Planning Poker
Planning Poker offers a number of advantages:
- It promotes the exchange of information about the tasks and thus a common understanding of the participants or team members.
- It promotes team cohesion, as the shared estimate creates a shared responsibility.
- It creates a commitment of the team, since there is quasi automatically an acceptance of the estimate. Especially in contrast to “externally given estimates”, this is an essential success factor on the way to later realisation.
- The combination of simple rules of the game and targeted moderation ensures a structured process. As a result, not everyone discusses with everyone, but two participants who must find a common denominator together. This saves time and often also nerves.
- The quality of the estimation increases because each participant can present his or her point of view and therefore everyone is heard. In addition, information is shared between the participants in the course of the discussion that might otherwise have remained hidden. The “expert knowledge” increases.
- The effect of the so-called anchor heuristic is avoided, where participants are (unconsciously) influenced by previously mentioned effort estimates.
- Even introverted participants can have their say (unless they consciously try to avoid discussions by estimating effort with apparent mean values. If in doubt, the moderator would be called upon here).
- And last but not least: Planning Poker is great fun!
Tips for Planning Poker
There are also a number of valuable tips on Scrum Poker:
- Product owners, stakeholders or line managers should not participate in the estimation rounds. Experience shows that external factors – company policy, individual image, internal or external milestones – can distort the effort estimation.
- Ideally, the product owner should be available during the planning poker game and be ready to answer questions.
- Some publications recommend limiting discussions to one minute, but this may be too short, as the focus is ultimately on agreeing on a common estimate. In fact, however, the use of maximum timeboxes – e.g. with 5 minutes – makes sense. Here, organisations should gather their own experience and make individual agreements.
- It helps in practice if a concrete backlog item, e.g. a user story, is used as a reference. It provides orientation for the employees involved.
- The definition of Done should also be taken into account, as the relevant criteria must be met during subsequent implementation. The effort required for this must be included in the estimate. The moderator should point this out again and again.
There are also a number of “bad” pieces of advice that are repeated regularly. Some claim that estimates should only be given by those who are also working on the implementation of the task. If the Scrum Poker takes place in Sprint Planning, it is unclear who will take over which task later on in the implementation. Sometimes it is also advised to consider the higher estimate in case of uncertainty. In individual cases this may be correct, but it would certainly be better to reduce the uncertainty and define spike stories, for example. As soon as there is clarity about the actual scope of the task, nothing stands in the way of estimating the effort in a later Planning Poker.
Impuls to discuss:
Planning Poker is not mentioned in the Scrum Guide and is therefore not considered part of Scrum. Should this be changed in the next version of the Scrum Guide?
PLANNING POKER® is a registered trademark of Mountain Goat Software.
Here you can find a German Video about Planning Poker.
And here you can find additional information from our Smartpedia section: