Presenting the task
A good task presentation is the foundation of an accurate estimate. It helps the team focus on the essence of the problem and make an informed judgment. The task is usually presented by the product owner or project manager, whose job is to give participants a full understanding of what needs to be done:
- Start with a short description of the task. For example: "We need to build an autosave feature for the text editor." Then go into the details: how often to save, what happens when the connection drops, how the feature interacts with others.
- Use visual materials. Show mock-ups, diagrams or prototypes if you have them. Visuals help the team understand the task better and shorten the discussion.
- Explain the business value of the task. Why does it matter to users or customers? How does it relate to the overall project goals? Understanding the context helps the team make more balanced estimates.
- Be ready to answer questions. The team may ask about technical constraints, integration with existing systems or user expectations.
- Keep the presentation to 5–10 minutes. If the task is complex, break it into subtasks and present each one separately.
- Make sure everyone understands the task the same way. This helps avoid misunderstandings during estimation.
Individual estimation
After the presentation, each participant independently picks a card with the number they believe reflects the task's complexity. Then, at the facilitator's signal, everyone reveals their cards at once to start the discussion. A few things to keep in mind at this stage:
- Don't rush participants. Each team member needs time to analyze the task and compare it with their own experience. Participants should consider every aspect of the work: coding, testing, documentation. For example, a developer estimates not only the time to write the code but also to go through code review and fix any bugs.
- Keep estimates independent. Participants should not show their choice or discuss it with colleagues before the cards are revealed. This prevents senior voices from influencing others and gives an honest picture.
- Use the "?" card for complex or unclear tasks. It signals that more discussion is needed.
- Don't fixate on exact numbers. Pick the nearest value available on the cards. The goal is to get a general sense of the task's complexity, not a precise number of hours or days.
Discussing the results
The discussion is the most valuable part of Planning Poker. This is where the team uncovers differences in how it understands the task and works toward a shared view.
If everyone chose similar values, say 5 and 8, the discussion can be brief. But with a wide spread, say from 3 to 21, the situation needs clarifying. Participants with the extreme estimates speak first. For example, the developer who chose 3 explains: "I think we can use an existing library, which will make the task much simpler." The one who chose 21 may counter: "But we'll have to adapt that library to our needs, which will take extra time."
It is important to create an atmosphere of open dialogue in which everyone feels comfortable sharing their view. The facilitator makes sure the discussion stays a constructive exchange of ideas and does not turn into an argument.
Don't let the discussion drag on: 5–10 minutes per task is optimal. If the discussion runs long, the task probably needs to be broken into smaller subtasks. After the discussion, the team votes again; the second round usually produces estimates that are much closer together.
Reaching consensus
After the discussion and re-vote, the team usually arrives at an agreed estimate. If the estimates have converged — for example, most chose 8 and a couple of people chose 13 — the team can take the average or round up.
If disagreement persists, the facilitator suggests another round of discussion to find out why. The goal of this stage is not to force the whole team to agree on a single number but to reach a shared understanding of the scope and complexity of the task. Small differences are acceptable as long as the team is aware of all the risks and complexities.
How to get the team more engaged in Planning Poker
To make Planning Poker an engaging and productive process rather than a formality, try the following techniques:
- Create a game atmosphere. Use unusual cards or add an element of competition. For example, award a small prize to the participant whose estimate came closest to the final one.
- Rotate the facilitator role. Give every team member a chance to run a session. This increases everyone's sense of ownership and engagement.
- Visualize the process. Use a board or online tools to display estimates and progress. A visual element sparks interest and makes information easier to take in.
- Hold mini-retrospectives. After each session, set aside 5–10 minutes to discuss what went well and what could be improved. This helps the team keep refining the process.
- Link estimates to actual results. Periodically compare estimates with the time actually spent. This helps the team calibrate its estimates and see the value of the process.
- Encourage knowledge sharing. Create an environment where experienced team members share insights and newcomers can ask questions without hesitation.
- Experiment with the format. Try running Planning Poker standing up or in an informal setting, such as a park or a café. A change of scene can refresh perspectives and stimulate creative thinking.
Common Planning Poker mistakes and how to avoid them
Planning Poker sessions can suffer from mistakes that reduce the technique's effectiveness. Fortunately, these common pitfalls can be fixed:
Mistake: discussions that run too long.
How to avoid it: set a 5–10 minute timer for each task; if the team cannot agree, park the task and come back to it later.
Mistake: senior team members influencing others' estimates.
How to avoid it: ask junior team members to speak first.
Mistake: estimating time instead of complexity.
How to avoid it: use abstract units of measure, such as story points.
Mistake: insufficient preparation and poorly worded tasks.
How to avoid it: require the product owner to describe tasks clearly before the session; postpone estimation if a task is unclear.
Mistake: overlooking "invisible" work such as testing, documentation and communication.
How to avoid it: create a checklist of all stages of work on a task and refer to it during estimation.
Summary
Planning Poker is an effective technique for estimating tasks in Agile development that helps teams forecast the complexity and duration of work more accurately. A well-run Planning Poker session not only improves estimate accuracy but also helps the team better understand the project and identify potential risks.
