**Planning Poker** is a method of collective task estimation used in agile development methodologies, especially in Scrum teams. With the help of the method, the team can collectively estimate the complexity or labor intensity of tasks using special cards resembling a poker game.
## What is Planning Poker
The idea of planning poker was born out of a desire to make the estimation process more accurate - the method was developed by James Grening in 2002, adapting the Wideband Delphi technique for the needs of Agile teams. Later, in 2005, Mike Cohn popularized this approach in his book *Agile Estimating and Planning*.
Planning Poker involves the entire development team: programmers, testers, analysts, and others. Each participant receives a set of cards with numbers from the Fibonacci sequence, and these cards are used to estimate the complexity of the task.
The evaluation process looks like this:
1. a manager or product owner presents the task to the team;
2. participants ask questions to clarify details;
3. each team member selects a card with a score that he/she believes corresponds to the complexity of the task;
4. everyone shows the selected cards at the same time;
5. if there is a significant difference in scores, a discussion begins;
6. the process is repeated until the team comes to an agreement.
Planning poker helps to avoid the influence of authority on the evaluation because all participants show their cards simultaneously. In addition, the technique encourages the exchange of opinions and experiences among team members, so that the estimation becomes more accurate and participants better understand the tasks.
## Advantages and disadvantages of the technique
The Planning Poker method involves all team members in the task estimation - this allows all aspects of the project to be considered and a complete picture to be obtained. Because participants choose cards at the same time, the estimates are independent.
When estimates disagree, the team discusses the reasons. Such discussions help to uncover hidden risks and difficulties that might have gone unnoticed with other approaches.
Also, the game-like format of planning poker makes estimation more fun, which keeps the team engaged in the task discussion. If in the process the team comes across unclear task requirements, they can clarify the details with the customer in a timely manner - so the method helps to improve the quality of planning.
However, Planning Poker has drawbacks - the main problem remains the subjectivity of assessments. Since participants rely on personal experience, the results can be skewed. Often the evaluation takes a long time, especially when there are a large number of tasks or serious disagreements in the team. Lengthy discussions can reduce overall productivity. Sometimes the team comes to a common decision not because of an objective assessment, but because of group pressure.
It is also difficult for beginners to apply Planning Poker because unfamiliar tasks are difficult to evaluate without relying on previous experience. Experienced participants, in turn, can manipulate the scores - intentionally overestimating or underestimating numbers to influence the overall result. This behavior distorts the final score and undermines trust in the team.
## How Planning Poker works
Planning Poker resembles a card game, but instead of regular cards, participants use a special deck of numbers. These numbers usually represent the Fibonacci sequence: 0, 1, 2, 3, 3, 5, 8, 8, 13, 13, 21, 34, 55, 89. This set of numbers is not random - it helps avoid false precision in estimates and stimulates discussion when there are large discrepancies.
The estimation process usually starts with the product owner presenting the task to the team. He describes the requirements, answers questions, and clarifies details so that the team has a full understanding of the task. Each participant then selects a card with a number that they believe reflects the complexity or labor intensity of the task. Participants keep their choice secret until everyone has decided on an estimate.
Then, on a signal from the moderator, everyone simultaneously shows their chosen cards. If the scores are the same or close to each other, the team usually accepts the average and moves on to the next task. However, the most interesting part starts when the scores are very different - in such cases, the participants with the lowest and highest scores explain their choice.
After the discussion, everyone chooses a card again, and the process is repeated until the team reaches a consensus. This approach allows different points of view to be taken into account and a more objective assessment of the task to be reached.
The Planning Poker method works well in small teams of up to 10 people. For larger projects, you can divide the team into sub-teams, each of which will evaluate a different part of the task.
## Step-by-step Poker Planning Process
Each step in the Poker Planning process plays an important role in forming an accurate and consistent estimate. Below - more details about each step and tips for team success.
### Session Preparation
The success of Planning Poker relies heavily on thorough preparation:
1. **Choose a time and place that is convenient for everyone**. A spacious room with a large table for offline meetings, or a video conferencing platform for remote teams.
2. **Determine the composition of the participants.** Ideally, all members of the development team should attend the session, including programmers, testers, and analysts. Don't forget to invite the product owner - their participation is critical to clarify requirements.
3. **Prepare decks of cards for each participant. **A standard set includes cards with Fibonacci sequence values: 0, 1, 2, 3, 5, 5, 8, 13, 21, 34, 55, 89. Also add a card with "?" to indicate uncertainty and "∞" for overly difficult problems.
4. **Make a list of tasks to be evaluated in advance**. Make sure each task is clearly stated and understood by all participants. Arrange the tasks in order of priority, starting with the most important.
5. **Appoint a moderator for the session**. This role is usually filled by the Scrum master or project manager. The moderator should keep track of time, guide the discussion, and ensure a constructive discussion.
6. **Establish rules for the session**. For example, limit the discussion time for each task to 10-15 minutes. Agree that after two rounds of voting, if consensus is not reached, the team will take an average of the scores.
7. **Prepare tools to record the results**. This can be a simple Excel spreadsheet or specialized project management software.
### Task presentation
A quality problem presentation is the foundation of an accurate assessment. It helps the team to focus on the essence of the problem and make an informed decision. Usually, the task is presented by the product owner or project manager, his task is to give the participants a full understanding of what needs to be done:
1. **Start with a brief description of the task**. For example: "We need to develop an auto-save feature for a text editor." Then reveal details: frequency of saves, behavior when connection is lost, interaction with other features.
2. **Use visual materials**. Show mockups, diagrams, or prototypes, if available. Visualization helps the team better understand the task and reduce discussion time.
3. **Explain the business value of the task**. Why is it important to users or customers? How does it relate to the overall project goals? Understanding the context helps the team make better decisions when evaluating.
4. **Be prepared to answer questions**. The team may ask about technical limitations, integration with existing systems, or user expectations.
5. **Deliver the presentation in five to 10 minutes**. If the task is complex, break it down into subtasks and present each one separately.
6. **Make sure everyone understands the task in the same way**. This will help avoid misunderstandings during the evaluation phase.
### Individual assessment
After the presentation, each participant independently selects a card with a number that they think reflects the difficulty of the task. Then, at a signal from the moderator, everyone shows their cards at the same time to begin the discussion. Here are a few aspects of this stage to keep in mind:
1. **Don't rush participants**. Each team member needs to analyze the task and compare it to their experience. Participants should consider all aspects of the work: coding, testing, documentation. For example, a developer estimates not only the time to write code, but also to conduct code review and fix possible bugs.
2. **Make sure that evaluations** are**independent**. Participants should not show their choices or discuss them with their colleagues until the cards are revealed. This helps to avoid the influence of authority figures and get an honest picture.
3. **For complex or unclear tasks, use the "?" card.** It will signal the need for additional discussion.
4. **Don't get hung up on exact numbers**. Choose the closest value available on the cards. The purpose of the assessment is to get a general idea of the complexity of the task, not an exact number of hours or days.
### Discussing the results
The discussion phase is the most interesting part of planning poker. It is during this stage that the team finds discrepancies in the understanding of the task and works to form a common opinion.
If all participants have chosen close values, such as 5 and 8, the discussion may be short. However, if there is a significant difference, for example, from 3 to 21, it will be necessary to clarify the situation. Participants with extreme scores are the first to speak. For example, the developer who chose 3 explains, "I think we can use an off-the-shelf library, which will make the task much easier." And the one who chose 21 might argue: "But we will have to adapt this library to our needs, which will require additional time".
It is important to create an atmosphere of open dialog - everyone should feel comfortable expressing their opinions. The moderator makes sure that the discussion does not turn into an argument, but remains a constructive exchange of ideas.
Do not prolong the discussion, the optimal time is 5-10 minutes per task. If the discussion drags on, the task may need to be broken down into smaller subtasks. After the discussion, take a second vote; usually the second round will yield closer results.
### Reaching consensus
After discussion and a second vote, the team usually arrives at a consensus estimate. If the estimates are closer together, e.g., the majority chose 8 and a couple people chose 13, the average can be taken or rounded up.
If disagreement cannot be gotten rid of, the moderator suggests an additional round of discussion to find out the reasons for the discrepancy. The purpose of the stage is not to force the whole team to agree on one number, but to come to a common understanding of the scope and complexity of the task. Small discrepancies are acceptable as long as the team recognizes the risks and complexities involved.
## How to increase team engagement in Planning Poker
To make Planning Poker a fun and productive process rather than just a formality, try the following techniques:
- **Create a game atmosphere**. Use unusual cards or add a competitive element. For example, award a symbolic prize to the participant whose score is closest to the final score.
- **Rotate the role of moderator**. Give each team member the opportunity to moderate a session. This increases accountability and engagement for all participants.
- **Visualize the process**. Use a whiteboard or online tools to visualize grades and progress. Visuals stimulate interest and make it easier to absorb information.
- **Conduct mini-retrospectives**. After each session, set aside 5-10 minutes to discuss what went well and what could be improved. This will help to continually improve the process.
- **Link evaluations to actual results**. Periodically compare estimates with actual time spent. This helps the team calibrate their estimates and see the benefit of the process.
- **Encourage knowledge sharing**. Create an environment where experienced team members can share insights and newcomers can ask questions without embarrassment.
- **Experiment with the format**. Try holding Planning Poker standing up or in an informal setting such as a park or coffee shop. A change of scenery can refresh perceptions and stimulate creative thinking.
## Planning Poker mistakes and how to avoid them
Conducting planning poker can come with mistakes that can affect the effectiveness of the method as a team. Nevertheless, these common mistakes can be solved:
**Mistake**: discussing too long.
**How to avoid**: set a timer for 5-10 minutes to discuss each task; if agreement cannot be reached, postpone the task and come back to it later.
**Mistake**: the influence of authority on other participants' evaluations.
**How to avoid** it: invite junior team members to speak first.
**Mistake**: estimating time instead of complexity.
**How to avoid**: use abstract units of measurement such as story points.
**Mistake**: insufficient preparation and poorly defined tasks.
**How to avoid**: require the product owner to clearly describe the tasks before the session; postpone the evaluation if the task is unclear.
**Mistake**: ignoring "unnoticed" work such as testing, documentation, and communication.
**How to avoid**: make a checklist of all the steps in the task and refer to it when evaluating.
## Summary
Planning Poker is an effective method for estimating tasks in Agile development that allows teams to more accurately predict the complexity and time to complete projects. Properly organized planning poker not only improves the accuracy of estimates, but also helps the team better understand the project and identify potential risks.
