Priority Poker or Planning Poker

Prioritization significantly influences the development of a solid roadmap for Agile/Scrum organizations. It is a challenging and time-consuming task unless you have an easy and effective technique that helps to find out the right order of work. Luckily, there are various techniques for feature prioritization that we have been exploring for a development team setting.

Some techniques use gamification to effectively prioritize the work, from making initial estimates to handling product backlog items. Let's explore one such gamified prioritization technique called ‘Priority or Planning Poker.

What is Priority/Planning Poker?

Priority poker is a gamified technique that uses a consensus to estimate the time and effort required for each task of a product backlog. This estimation process is known as ‘planning poker’, ‘scrum poker’, or ‘pointing poker. This prioritization technique is similar to a poker game in which the product teams use physical cards similar to poker cards and estimate the number of story points required for each task. This technique helps agile teams to be more strategic in prioritizing the most important work with high enough accuracy (we want an accurate estimate as best as we can, spending as little effort as possible estimating). Since this technique creates a consensus among each game participant, it is a more inclusive prioritization technique.

Planning Poker originated in Utah, USA, in 2002 when a team of software developers was trying to get out of a planning deadlock between two senior staff members. Team member James Grenning suggested using a variation of the then-popular estimation approach Wideband Delphi method giving rise to the planning poker method. Planning poker was initially just a “solving the problem of people in agreement talking too much and dominating the effort. Later, it became a popular estimation technique for estimating and planning any agile project with Scrum teams.

How to use Planning Poker for estimations and prioritization?

A planning poker session generally starts with meeting all the required stakeholders, including product owners, product managers, developers, UX designers, etc. Before starting this game, the team should agree on the numbering scheme used for the poker cards. In general, the product owner distributes the cards and reads out a user story in the backlog describing the specific software feature and how it provides value to the customer. Then the team reaches a consensus based on effort estimation by each team member.

Therefore, this game generally follows the following steps in order.

Poker card distribution

First, the product owner distributes an identical deck of cards to each participant. As the team agrees before starting this game, each card has a number reflecting the estimate of the user story. For example, the numbers can be a sequence of 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100 or a sequence that doubles each number like 2, 4, 6, 8, etc. At the end of the poker card distribution, each team member will have a deck of cards having different numbers. This number usually reflects the number of points required to complete each user story, the number of days, or any other estimation agreed upon by the team.

Explain the user story

After the first step, the product owner explains the user story they will estimate. The product owner also answers any questions that come from the team. After explaining the user story, each team member shares their thoughts, like the number of developers they think will be required for it, the skills required, dependencies, roadblocks, etc. This step lets team members get to know each user's story in detail and clear any doubts they have.

Select a card to provide the individual estimation

Next, each team member decides on a story point for the user story and selects the appropriate card from the card deck to represent their estimations. The team shows their cards at the same time.

Reaching the consensus

If all the team members have selected the same card, you can easily conclude the estimation for the discussed story. However, if there is a significant variation from the cards selected, the team starts a discussion on why they have come up with that estimation. Usually, members with higher and lower estimations share their views, and other team members communicate their thoughts on those points. Once the team gets their doubts cleared and reaches a better common understanding of the user story, they again go through the card selection process. They can reach a consensus if the second round has a higher number of the same card. It fails this time. Also, they need to repeat this step until they can come to a consensus.

The team goes through the same process for the user stories they need to prioritize. Once the team has found the estimations for all the user stories, the product owners can decide on the priority order of the user stories and epics to include in their next road map.

Today, you can use several poker-planning software and apps to play this game if you are working remotely.

Benefits of Planning Poker for Prioritization

Planning poker provides many benefits for teams working in Agile/Scrum environments. For example:

• Reduces the bias of team members towards certain user stories
• Improves communication and collaboration among team members
• Helps uncover insights from other team members and incorporate their valuable opinion to improve the user stories and estimations
• Improve the inclusiveness across teams.
• Helps discover gaps in requirements and understand each task in the product backlog

Since this uses a consensus, the estimation and prioritization are more accurate.

Summary

Prioritization is the key to successful project and roadmap planning. I usually teach teams that our Product Teams can't estimate the value of items unless they know the cost. Poker planning is a prioritization technique based on individual task estimation, which provides product owners and stakeholders with a gamified planning experience around the cost or size of the work.

In this technique, the entire team gets together and provides an estimation for each user story using a physical card. Based on the estimation, the team can come to a consensus on the estimation. If their cards have a larger variation, the process will be repeated until they reach a final consensus.

After estimating every user story in the backlog in this way, product owners can easily decide on the priority order. This technique is simple but provides many benefits like improving inclusiveness, communication, and collaboration and reducing bias or influence of team members.