Planning Poker
Master Planning Poker (SCRUM Poker), a collaborative estimation technique used by Agile teams to estimate task difficulty through consensus. Learn the process, benefits, and best practices.
Planning Poker
The Agile method of planning poker consists of a difficulty estimation of tasks founded on a consensus.
The Planning Poker, also known as "SCRUM Poker" or "pointing poker", is a playful method that development teams use for project management tasks. These estimations are based on a consensus from the whole team, which makes it more accurate than other methods. To help evaluate story points count for relevant tasks, teams use planning poker cards.
Card Values and Fibonacci Sequence
The Fibonacci sequence is used for evaluations. Since we seek to quantify the effort, the message is clear: the bigger the scenario is, the less accurate evaluations will be.
Note:
The cards pack used for Planning Poker must contain the following values: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144.
Some teams simplify large values by turning them into 20, 40, 100... because the idea is to "be globally good" instead of "be accurately wrong". We generally add 0 and 1/2 values as well.
Card Value Meanings
How Planning Poker Works
At the beginning of a Planning Poker session, the Product Owner or the client reviews an agile user story and reads it aloud. A user story is a general and informal explanation of a software feature that describes how it will deliver value to the end user.
The Process
Distribute Cards
Distribute an identical set of cards to each participant. Each card has a number agreed upon by the team. Mike Cohn recommends a sequence of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 in his book "Agile Estimating and Planning."
Read the Story
The moderator (Product Owner) tells the story to the group. If participants have questions, the moderator answers them.
Discuss the Story
After the group has finished listening to the story, each person shares their perspective on it.
Select and Reveal
After the discussion, each person privately chooses a card from the deck. Once everyone has chosen a card, they reveal them simultaneously.
Achieve Consensus
When team members show the same card, that number becomes consensus. If cards vary, further discussion follows until agreement is reached.
Detailed Process Steps
1. Distribute Cards to Participants
Note:
Each player should have a set of cards with different numbers. These values can represent a variety of things: the number of story points, ideal days, or other units the team uses for estimation.
The card sets intentionally have a minimal level with significant jumps in numbers. This ensures that for each story, everyone can reach a consensus number. If there were a card for every number from 1 to 50, the process would be terribly slow.
2. Read the Story Aloud
The moderator (Product Owner) tells the story to the group. If participants have questions, the moderator answers them with sufficient detail for accurate estimation.
3. Discuss the Story
After the group has finished listening to the story, each person shares their perspective on it. Some of the discussion points will likely include questions like:
- How should we approach the work?
- How many people are expected to be involved?
- What skills will be needed to work on the story?
- How to address obstacles that hinder progress?
The group will also try to learn more about the story and ask questions to better understand it.
4. Select and Reveal
After the discussion, each person privately chooses a card from the deck. Typically, it's used to show an estimation of the story points (but it can also represent the number of ideal days). Once everyone has chosen a card, they reveal them simultaneously.
Note:
If a player shows a higher card, it means the story will be completed with more difficulty and more time committed. Keep in mind that it's common for estimates to vary significantly initially.
5. Achieve Consensus
When team members show the same card, that number becomes consensus. At that point, the group can proceed and work on the next story. However, if the cards continue to vary, further discussions about the story will follow.
Note:
Participants whose estimates are higher or lower than others will communicate their perspective. They will then attempt to explain to their teammates the reasons for the divergence. Once this additional deliberation is complete, everyone will review their cards and reveal them again.
Generally, estimates start to converge after the second round. If that's not the case, the process is repeated until the team agrees on a single number.
Benefits of Planning Poker
According to studies, estimates from Planning Poker are statistically more accurate than individual estimates.
Key Benefits
Who Should Participate in Planning Poker
The right people need to join the meeting, otherwise, it becomes difficult to reap the benefits described above. These crucial roles are as follows:
Note:
Essential Participants:
- Scrum Team Members: Provide items for the Product Backlog and contribute to discussions on story points
- Scrum Master: Facilitates agile meetings and should participate in all (or nearly all) meetings
- Product Owner: Describes all user stories to the team and answers their questions
Optional Participants
- Technical Architects: For complex technical stories
- UX/UI Designers: For user interface and experience stories
- Quality Assurance: For stories with significant testing implications
- Subject Matter Experts: When specialized knowledge is required
When to Organize Planning Poker Meetings
Initial Planning
In general, teams organize a session after creating the initial backlog. While sessions can sometimes take more than one day, they help in establishing useful initial estimates for project sizing or scoping.
Ongoing Planning
Items are added to the Product Backlog incrementally throughout the project's lifespan. That's why it's typically more practical for teams to conduct sessions once per iteration.
Note:
Best timing practices:
- After sprint completion: A few days after the end of the iteration
- During backlog refinement: Regular grooming sessions
- Just after daily standup: When the whole team is present
- Before sprint planning: To have estimates ready for planning
Session Frequency
- Weekly: For teams with rapidly changing backlogs
- Bi-weekly: Most common approach, aligned with sprint cycles
- Monthly: For stable teams with well-defined backlogs
- Ad-hoc: When new complex stories are added
Best Practices and Tips
Keep Sessions Focused
Limit sessions to 2-3 hours maximum. Break large sessions into multiple shorter ones.
Prepare Stories in Advance
Ensure all stories have clear acceptance criteria and are well-defined before the session.
Don't Average Estimates
Work toward consensus rather than mathematical averages. The discussion is more valuable than the numbers.
Break Down Large Stories
If a story receives consistently high estimates (13+), consider breaking it into smaller pieces.
Document Assumptions
Record key assumptions and decisions made during estimation for future reference.
Conclusion
Planning Poker is a powerful technique that combines the benefits of expert estimation with team collaboration. It helps teams create more accurate estimates while building shared understanding and identifying potential issues early in the development process.
Note:
Key Success Factors:
- Ensure all team members participate actively
- Focus on discussion and understanding, not just numbers
- Use estimates for planning, not for measuring team performance
- Continuously refine your estimation skills as a team
The collaborative nature of Planning Poker makes it an essential tool for Agile teams looking to improve their estimation accuracy and build better products through shared understanding and consensus-based planning.