The planning poker technique gets used by agile teams all over the world to estimate their product backlogs. Typically, story points evaluate the complexity of a story, and writers gather various expert opinions for the estimation.
This article will walk you through the process of hosting your first Planning Poker Session.
Planning poker is a task or project estimation strategy in which teams use a deck of poker cards to estimate the size or scope of various projects and tasks.
After a particularly slow and tedious meeting, James Grenning created planning poker. The game then gained popularity thanks to Mountain Goat Software's Mike Cohn. Cohn adapted the planning poker game to utilize a modified sequence of optimized numbers for reporting in his book "Agile Estimating and Planning." It provides a highly effective method for estimation that can benefit most agile teams.
The game is not hard to grasp, as you will see later on.
First things first, you will need a wide table and 2-4 hours for the meeting and a set of cards for each team member. You also have to consider the following factors:
Everyone involved in the project gets invited to play the Planning Poker: programmers, testers, database engineers, analysts, user interaction designers, and whoever else. These team members are most suited for the estimating assignment because they represent all disciplines on a software project.
Although there is no defined size for a Scrum team, the Scrum Guide recommends keeping it between 3 to 9 people. Any smaller, and it becomes difficult to complete a meaningful amount of work in fewer iterations; any larger, and the team will struggle to manage the overhead.
You can also use this principle to determine how many individuals should be present simultaneously during a Planning Poker session. If you have more than this, you might want to divide into teams and play different games of Planning Poker.
Although the Scrum Master and Product Owner are welcome to attend Planning Poker, estimating should be done by the team members who will be completing the task. The Product Owner should still be there to assist the team in clarifying questions regarding functionality and scope. The Scrum Master should provide direction on issues that may hinder the team from moving forward with their estimations. However, the team in charge of estimating will be the ones that commit to complete the job throughout the session.
When playing Planning Poker with a larger group, one of the problems is that people fall into the habit of pointing according to their area of expertise. As a result, a team member who is more familiar with front-end development may point to a "front-end" story, while a designer will point to a "design" story, and there are a few concerns with this.
First, if this is the case, stories are most likely not being produced or split correctly, as they should be focusing on vertical slices of functionality rather than horizontal split components of stories.
Another concern is that it provides the idea that the estimates are precise. One of the main purposes of using tools like story points and Planning Poker is to avoid falling into the trap of trying to come up with estimates that are too precise and will almost certainly be erroneous.
Finally, when teams estimate along these lines, the amount of discourse surrounding each story is reduced, and everyone is less involved in a story, not in their domain.
After an initial product backlog gets produced, most teams will attend a poker planning session. These sessions, which can last several days, are intended to generate preliminary estimates to help with product planning and sizing.
Most teams find it advantageous to have additional agile estimating and planning sessions once per iteration because product backlog items – frequently in user stories – will continue to be added throughout the project.
Because the entire team is still present, these are usually held a few days before the conclusion of the iteration and shortly after a daily standup.
At this juncture, you will see how a Planning Poker session typically gets carried out.
A deck of regular playing cards or bespoke Planning Poker cards gets presented to each participant. As recommended by Mike Cohn, each card will get assigned a value, such as 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
If you are using regular cards, you will need to develop a theme for yourself — for example; you could give the King of Hearts 100 points. The numbers reflect the number of story points, ideal days, or another team’s unit to estimate.
Because the goal is for all participants to obtain a consensus number for each story, the decks are limited, with substantial number jumps. Giving participants too many alternatives, such as every number between 1 and 50, would render the process wasteful because the results would be too similar across the board.
The user story will be read to the group by whoever is leading the session. This step gets followed by a discussion of different approaches to the goal, an estimate of how many people will be needed, the skill sets that will be necessary, and any potential challenges that may arise.
This time is also a good moment for the group to clarify any inconsistencies.
It is time to play poker after everyone is on the same page with the user story.
Each player will select a card from their deck to symbolize their story point estimation in secret. When everyone has made their decision, the team simultaneously reveals their cards. The greater the number on a participant's card, the more effort the story is expected to require. Some engineers estimate based on complexity instead of effort, however, this leads to inaccurate estimations as complexity is not equivalent to output. So, estimate the effort of the story to ensure all estimates are useful and accurate.
There is a good chance that no two people will reveal the same card. However, if they do, that figure will become the official estimate, and the team will move on to the next user narrative.
If the cards are not the same, the team will have to revisit this user story. Those who have played a higher or lower card than the average will explain their reasoning. The goal of this explanation is to persuade the rest of the team to agree.
The team will play again after the second round of deliberation is completed. Depending on how the discussion went, the group will play a different card corresponding to the points stated, or they will just play their initial choice again if they are not convinced.
If the team chooses to play the same cards as the first draw, the outlier vote is removed from consideration, and the average rating is utilized as an estimate.
There are no definitive answers for what works best in a Planning Poker session, as there are for most things. The most important thing is to keep assessing and adapting as the project goes and focus on facilitating effective team communication so that everyone understands their role. This fluidity will take some time and practice, but it is possible with the correct tool.
In this regard, check out how Asynch Poker can help you today!
