9 Common Mistakes with Planning Poker & Their Remedies

Planning Poker is an estimation technique that is easy to learn but difficult to master. By avoiding mistakes linked with it, you can have accurate estimates.

Planning Poker is one of the widely used estimation techniques by Scrum teams to estimate the efforts required to complete product backlog items. If done rightly, it can deliver outstanding results and accurate estimates of the work. However, if done wrongly, it can lead to inaccurate estimates, waste of time, delays, and low-quality deliveries. So, it is important that we know some of the common mistakes with Planning Poker that most Scrum teams do so that we can reduce the chances of their occurrence. Therefore, this blog discusses the 9 common mistakes with Planning Poker and their remedies.

9 Planning Poker Mistakes & Their Remedies

Planning Poker is easy to learn but difficult to master. Following are the common mistakes around Planning Poker you should know:

1. Works instead of Efforts

Planning Poker is a relative estimation technique that urges the team to discuss and estimate the efforts required to complete the task instead of discussing and finalizing the required time. Since Scrum-based development is mostly practiced by software development firms, so they have the habit to evaluate everything in terms of time. If a team estimates user stories based on time, then they are actually ignoring the basic objective of Planning Poker, i.e., to promote team discussion around the lined-up tasks for better prioritized planning and focused development.

The best remedy for the team to get rid of this mistake is to avoid evaluating user stories based on the time it will take to deliver. Instead, they should focus on team discussion to accurately estimate the efforts.

2. Influence of Scrum Masters

Scrum Masters that are not much experienced with the Planning Poker technique often make mistakes unintentionally. One such mistake is that they like to influence their estimation size over other members. So, they lead the team to the desired answer instead of making the team reach the answer through discussion and proper understanding of the work. Some Scrum Masters even directly declare the value/size of the story point after they finish reading the story.

The right strategy is that Scrum Masters do not intentionally or unintentionally influence the estimation process of team members. They should give the environment the team needs to understand story points and then later present unbiased estimates based on their understandings.

3. Select Size One at a Time

Some teams that practice Planning Poker let their members select size one at a time. However, Planning Poker urges that all members present their sizes at the same time. So, if members are asked to select size one at a time, it will make the influence of experienced members dominate and impact the thinking capability of other members.

The right approach is that members are allowed to carry out discussions around a story point freely, which implies that all members can clear their concepts freely. Once done, they should be allowed to pick the card without letting others know, and then they should all present their cards at the same time. This way, members that give the highest and lowest value will get a chance to present their viewpoints, eventually leading to an accurate final team estimate.

4. Too Many Stories

Some teams often try to be more proactive and tend to estimate too many stories. For example, if a team is capable to complete 5 stories in one sprint session, it sometimes intends to complete 10 stories. The Planning Poker technique does not restrike a team to the number of stories it can estimate, but a team should only estimate the number of stories it can complete easily. Otherwise, it's just a waste of time and poor-quality performance in the end.

What teams should do is they should know how many stories they can complete in one sprint session on average. Based on that, they should try to estimate only that number of stories. However, if stories are easy, then they can add more. But they should never burden themselves with extra work just to be more proactive.

5. Unintentional Group-Think

Group-think is a phenomenon in which individuals unintentionally agree with the opinion of the broader group (experienced individuals) to avoid any conflicting situation. Since a Scrum team involves both experienced and new members, it is common to see group-think phenomena there. In an estimation session, if members agree with estimates provided by other members without involving any discussion, then it shows the influence of group-think.

The best remedy for this mistake is "encouragement". Members should be encouraged to speak and present their narrative no matter how much it deviates from others. They should have confidence that their viewpoint brings new insights that seniors might be ignoring. This way, teams can gradually minimize the influence of group-think.

6. Customization of Poker Cards

It is found that some Scrum teams have the habit to customize poker cards that they think are most suitable for the current sprint. For example, some teams have a "?" card that is meant to reflect that the member asks for more clarification. If a team starts using the "?" card frequently, it leads to unnecessary and lengthy discussions that can compromise the whole estimation process. Similarly, some teams have set 8 or 13 as the maximum size of the story to accelerate voting. But it can cause inaccurate estimates because it does not always reflect the true value the story should be assigned. For example, if a story is too large, the team still cannot assign a higher value to it.

The solution is to avoid customization of poker cards unless it is necessary. It is better if the team sticks with either Fibonacci (1, 2, 3, 5, 8, 13, 21) or modified Fibonacci series (1, 2, 3, 5, 8, 13, 20) and use it as it is unless there is a crucial need of customizing.

7. Lack of Right Members in the Session

For accurate estimates, it is necessary that all members that are going to be part of the development should be present in the estimation session. However, it is witnessed that often sessions are carried out with members that don't have a direct contribution in the development stage.

So, it is important that all members that are directly linked with development should be called to join the estimation session. Only then the team can lead to accurate estimates and proper guesses of the team's velocity can be made.

8. Point Value Creep

Point value creep is a condition in which story estimation gets larger with the passage of time. For example, a team at the beginning used to set a user story as a 5-point story, but now it has become an 8-point story somehow. This could be due to either the team is delivering more value over time or doing extra work. Although this seems good in the bigger picture, it can lead to more expectations from the team.

The solution to this issue is to calibrate user stories regularly. For example, look for the stories in the past that are similar to the current ones and compare the points assigned in both cases. This way, you can use the comparison analysis to easily calibrate user stories.

9. Too Long Discussions

Planning Poker requires that all team members join a session and remains attentive till all the product backlog items are estimated. But sometimes these estimation sessions can go very long if the members start making discussions longer. Planning Poker encourages discussion so that members can have a proper understanding, but it discourages longer discussions.

The right approach is that teams avoid making discussions too long and try to cover up things in small discussion sessions. However, it also does not mean members should not clear their doubts. The target is to adopt the smart approach in which members clear their concepts and discussions also remain short.

Moreover, if members don't have the time to take part in longer estimation sessions, teams can practice a modified Planning Poker technique known as Asynchronous Poker or Async Poker. Through this technique, members can estimate user stories at their own pace and deliver the estimates to the moderator before the deadline. Find out more about Async Poker by clicking here.

Final Words

Planning Poker is used by thousands of organizations owing to its simple and accurate estimation technique. However, it can lead to inaccurate estimates if done wrongly. Above we have discussed 9 common mistakes that Scrum teams intentionally and unintentionally do using the Planning Poker estimation session. But all those mistakes and similar others are resolvable. In fact, Scrum Master can play a key role here by pinpointing the mistakes and then finding ways to overcome them.