Planning Poker 101: Make Your Estimates More Accurate and Simple

Providing accurate estimates is one of the largest challenges for agile development teams, but planning poker aims to ease this burden with an effective method.

One of the most difficult obstacles that agile development teams encounter is an effective estimation. Scrum masters must identify, estimate, and allocate work throughout a team regardless of its size. Moreover, each project is unique and likely requires a different estimation.

Nevertheless, building excellent practices around planning and estimating work becomes increasingly more crucial as teams grow larger. It is essential to not only professionalism but the success of the project. Lack of planning and estimating undermines program confidence, shatters team-business ties, and makes development more difficult for everyone.

Good thing, there is a solution for that! Read on to know more.

Planning Poker: Explained

Planning Poker is a consensus-based agile estimating and planning technique. The product owner or client reads an elegant user story or presents a feature to the estimators to begin a poker planning session.

Each estimator has a deck of Planning Poker cards with values such as 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100, which is the recommended sequence. The numbers indicate the estimated number of story points which represent the amount of effort required for a specific task. This does not represent the complexity of a specific task or the time it takes to complete a specific task, but rather the effort required from the team to accomplish that specific task.

The estimators talk about the feature and ask the product owner questions as needed. After the feature has gotten thoroughly explained, each estimator chooses a card to represent their estimate in private. After that, all of the cards get revealed simultaneously.

The estimate gets established if all estimators chose the same value. If this is not the case, the estimators will discuss their estimations. You should share the reasons for the high and low estimates in particular. Each estimator reselects an estimate card after further discussion, and all cards get presented again, simultaneously.

The poker planning procedure continues until the estimators arrive at a consensus or when the estimators decide that you should postpone agile estimating and planning of a specific item until further information is available.

Why Play Planning Poker?

You are enforcing a process of constant learning by introducing Planning Poker. For one, you may know a developer who always overestimates a task or prefers to use an overly complex solution. On the other extreme, some developers are prone to underestimating jobs and failing to complete their work on time.

Estimation is no longer a single person's decision. Therefore Planning Poker can help. The team members with the smallest and greatest estimates will explain their choices, and at the end of the process, you will have a consensus estimate. Ultimately, Planning Poker enforces knowledge sharing in this way.

When is it Best to Engage in Planning Poker?

After an initial product backlog has gotten produced, most teams typically hold a Planning Poker session. This session, which could last several days, is intended to generate preliminary estimates to help with project scope and size.

Considering that product backlog items, usually in user stories, tend to get added during the project, most teams will find that conducting additional agile estimating and planning sessions once per iteration is beneficial. Because the entire team is present at that moment, this is usually done a few days before the conclusion of the iteration and shortly after a daily standup.

Planning Poker: How to Play

To play Planning Poker, one must have a good grasp of its rules.

First, you give a set of Planning Poker Cards to each team member. Afterwhich, the Development Team Leader or Moderator will present the first item on the backlog that must be estimated.

Then, from their set of Planning Poker Cards, each team member will choose an estimate. The card gets placed on the table with the number facing down so that no one else on the team can see their estimation.

When every team member has placed a card on the table, everyone flips their card to display their estimation. As a result, Planning Poker challenges everyone to think for themselves rather than simply putting down the same estimate as another team member.

Once all Planning Poker Cards get revealed, a team member with the smallest estimation and a team member with the highest estimate will explain their decision. Afterward, the team will quickly discuss the different points of view until a unanimous assessment gets reached.

After that, the next backlog item gets agreed upon, and the process gets repeated.

Planning Poker: Best Practices

You would assume that as your team grows older and more experienced, your estimates and planning poker sessions will improve as well. However, this is not always the case. In truth, the accuracy of an agile team's estimations tends to deteriorate over time.

The good news is that you can take steps to reverse this tendency and get your forecasts back on track. Here are some of the best Planning Poker practices:

• The people who should vote are the ones who could do the job. Too often, agile teams require everyone to vote, even if they do not know the story's work. Managers are not allowed to vote. Managers are usually motivated to make the work take less time. Hence, the vote frequently gets skewed to the negative.
• Managers, on the other hand, have more expertise than the typical team member. Thus, it may be prudent to give them veto power over team consensus in some situations.
• If there is a tie between two successive sizes, choose the larger one and carry on.
• Address the implementation arguments before they get out of hand. When discussing a user story, it's normal for teams to become bogged down in the technical specifics. To some extent, this is okay, but you should strictly regulate it. Set a time limit of one minute for discussions. The persons conducting the sizing should think of the simplest solution and choose a size based on that scenario. More debate may appear to make the measure more accurate, but this is just not the case.
• Use a card that says, "I need a break." Too often, teams will work tirelessly while playing planning poker, oblivious to the fact that some members of the team need a break. Someone can use the "I need a break" card to call everyone's attention to this.
• To keep conversation to a minimum, set a timer.
• If the group can reach no agreement at the end of the third round of voting, go with the largest size. Further discussion after two rounds of debate usually does not offer excellent outcomes for the time spent. The team will have an opportunity to improve by choosing the largest size, but they will not be in danger of running out of time. Because the group seeks to prevent running out of time, this particular shortcut should not pose any problems.
• Before playing planning poker, have the person producing the user stories meet with the QA and Development leads to ensure that the user stories contain answers to the most obvious questions the team will ask. This information helps the team to concentrate on the size rather than wasting time obtaining data.
• Keep the baseline in mind. Whatever the team chooses as a baseline must be maintained iteration after iteration. If a perfect day is a size 1, all iterations must use that as a starting point. If a user narrative has a size one or a size three, the size must remain consistent between iterations. After a few stories have gotten sized, it can be useful to bring up the baseline and question the team if the sizes are proportional to the baseline. Failure to do so could result in what is called a "size creep" over time. In other words, the team gradually adjusts their baseline to be greater or smaller than it is. This result frequently manifests as the team failing to reach their commitment over numerous iterations, despite everything appearing to be the same.
• Have a blast! Playing planning poker should be a pleasurable and cooperative experience. Too many teams strive to put in an hour or two of work and forget to enjoy it. You can infuse fun into the process in a variety of ways. For one thing, you can experiment with the sizes while playing real poker. Every sized narrative counts as a poker card, and a poker hand comprises five stories. Everyone tries to predict which hand will be the best poker hand before the game begins (for example, pick hand 1, hand 2, hand 3, and so on). This aspect of the game motivates users to review the user stories ahead of time. This way, they can hypothesize which set of five cards will result in a straight or four of a kind. Additionally, winners may also receive small tokens or prizes.

Conclusion

Planning Poker usually leads to a much more self-organizing team, has a higher level of commitment, and shares knowledge more effectively.

Consider using Async Poker, a solution for estimating your product backlog activities in Jira in an asynchronous method for collocated, distributed, or remote Agile teams, and get the most out of Planning Poker. Ultimately, Async Poker improves estimation accuracy without interfering with your development!