5 Planning Poker Tips and Tricks That You’ve Probably Never Heard Of

Planning Poker, usually considered the standard tool for conducting estimation for Agile projects, is a tool that is often misunderstood and misused. Throughout my years of coaching Agile teams, I have seen teams handle this process in very different ways, some of which failed to apply the tool properly without knowing it. I have personally observed many variations of the Planning Poker process, some effective and some dysfunctional. I will share a few of these with you to help you enhance the effectiveness of the estimation process for your Agile teams.

Before I share the tips and tricks, I would like to first clarify the objective of estimating work using Planning Poker as a tool. With these objectives in mind, we can focus on proper behaviors that will enhance our ability to meet such goals.

Objective #1 – Establish approximately scope of work that enables measurement of team velocity, which enables forecasting (e.g. release planning).

Objective #2 – Promote discussion regarding the scope of work required to meet the acceptance criteria for Product Backlog Items.

Tip #1 – Avoid converting work hours to story points

Teams that are new to Agile development often try to quantify everything, which is expected given that technically-minded people have a natural tendency to make sense of things through logic. In this context, using units of work hours is a much easier concept to grasp than relative sizing of work that accounts for effect, complexity, and level of understanding of the work. Teams that establish a formula (i.e. 8 hours per user story point) usually do not fully understand the value of relative estimates, which is to gain a high-level understanding of the work with minimal effort. Hence, I highly recommend you mentor new Agile teams to avoid this mistake; it will be challenging and likely stressful for technical team members to learn to estimate work with a unit-less measure such as a Story Point, so it will likely require somewhat of a leap of faith for them to experiment with it. Emphasize that this method of estimation enables the team to derive a team-level estimate, NOT an individual estimate, which will benefit the TEAM in the long run.

Tip #2 – Avoid group-think by being disciplined in the estimation process

Some teams that I have coached tend to become very lax with the Planning Poker process because it feels like a game rather than a serious approach to doing meaningful work, perhaps because having playing cards in your hand automatically disarms people? That’s difficult to know for sure. While it’s fine to keep things fairly casual, it’s important to manage the process and ensure that the team is spending their time wisely. One key pitfall to avoid is based on the concept of “group think”, which is the phenomena where individuals passively agree to the opinions of a broader group in order to avoid conflict, even if their opinion differs from the majority of the group.

In most cases, it’s hard to detect group think, but within the context of Planning Poker, it’s easier to see this happening, especially if the team members are agreeing with the estimates from other members of the team without any discussion. This is a negative behavior that takes away the effectiveness of the process. Encourage all team members to speak up and defend their positions; do not automatically change your estimate just because the senior member of the team has a very different estimate. Emphasize the fact that every individual brings an important perspective to the team, which is why they are given the opportunity to contribute their votes.

Tip #3 – Avoid excessive customization of Planning Poker Cards

Some teams that I have worked with have a tendency to customize the poker cards used for Planning Poker, meaning, select specific cards that they feel make sense to use for a specific sprint. My recommendation is that you choose a series, either Fibonacci (1, 2, 3, 5, 8, 13, 21) or modified Fibonacci (1, 2, 3, 5, 8, 13, 20) and stick with it. Do NOT change the series unless there is a good reason to do with with consultation from the Agile Coach. Some teams add the “?” card to allow team members to raise the need to acquire more information. I suggest using this card sparingly due to potential misuse.

Misuse of cards can become a big issue for the team is if continues to occur. Some teams have a tendency to misuse the “?” card by using this card excessively; this can lead to prolonged and unnecessary discussion regarding details of the User Story that may reduce the efficiency of the team and slow down the process. Some teams only use 1 through 13, 13 being the maximum size for a Story that can fit into a single sprint. While this may seem like an efficient way to ensure expedient voting takes place, it can lead to inaccurate estimates due to the absence of a way to indicate the story is too large to be fulfilled one sprint! The team can choose a 13 even if the Story is too large, simply because there is no other option. This may seem trivial on the surface, but over time, this will often lead to incomplete stories and wasted effort that result in incomplete work being carried to the next sprint.

Tip #4 – Ensure the right people participate in the Planning Poker process

Some of the teams I have coached feel the need to reduce the number of people that participate in the planning process because they feel that only the most experienced individuals understand enough about the product or system to be able to provide an accurate estimate. This kind of thinking is fundamentally flawed, given that the relative estimation process is not intended to derive an accurate estimate. When teams limit the number of participants to a subset of the entire team, you are essentially losing out on the experience and expertise of those members who are not engaged in the process. This can lead to much more harm than one might expect, from inaccurate estimates to degradation of team morale. My advice: engage the entire team (all the folks doing the work) when estimating work for the team!

Tip #5 – Avoid point value creep through calibration

When an Agile team has been working together for a few sprints, and has achieved visible success, some teams are encouraged to “produce more work”, which is an antipattern that is outside the scope of this article. The key thing to note here is that even the best and most experienced Agile teams may encounter a phenomena known as “point value creep”, which is a condition where the estimates of User Stories slowly become larger over time. For example, a User Story that used to be a 5-point story, has slowly become an 8 for whatever reason. This may occur naturally and mysteriously, and will generally lead to a perception that the team is doing more work and/or delivering more value over time; while this may seem like a positive, the risk is higher expectations that lead to increased pressure from leadership, which is a vicious cycle.

The technique that I recommend to mitigate the risk of this condition is regular calibration of the User Stories. There are likely many different approaches to achieving this, but one method is triangulation of Stories by taking previously-completed Stories (i.e. 2 points and 8 points) and compare to the current, active Story of 5 points, and assess whether this active Story is indeed a 5-point story. In addition, locate another 5-point Story from a previous sprint and compare it against the active Story to determine whether they match in terms of effort/complexity.

I believe that the Planning Poker estimation process is a skill that is “easy to learn, but difficult to master”, just as many other technique in Agile development. By looking out for potential pitfalls, you will be able to help your teams gain the maximum value from this tool.