10 Planning Poker Tips & Tricks

Planning Poker is a simple and fun way to estimate user stories. Scrum teams can elevate their Planning Poker sessions by following some key tips and tricks.

One of the great aspects of agile software development is its emphasis on effort estimation. A product backlog is difficult to prioritize if the team is unaware of the efforts required to complete user stories. Planning Poker is one of the most widely used estimation techniques due to its simple but powerful estimation approach.

Planning Poker presents a simple approach to estimation, but you will find different versions of it used by different teams. Teams often customize the technique to suit their needs, which can sometimes turn out to be productive or the other way around. Similarly, there is a perception that as the team gets mature, its estimation skills also improve. However, it is found that team maturity often results in the degradation of the team's estimation accuracy. Mostly it is unintentional but there are plenty of ways to tackle it. Therefore, this article will discuss some of the key tips and tricks around Planning Poker you must know for accurate estimates.

10 Planning Poker Tips & Tricks

Planning Poker is the leading estimation technique due to 3 main reasons, as follows:

1. It encourages collaboration by involving the whole team.
2. It pinpoints issues early during discussions of user stories.
3. It brings consensus estimation to the table instead of single-person estimation practice.

In short, Planning Poker, if done in the right way, can result in accurate work estimates and provide a good guess of the team's velocity. So, if you are also actively using the Planning Poker estimation technique in your organization, then follow the below tips to enhance your estimation accuracy:

1. Use Reference Story

A reference story is a perfect way to calibrate the estimates rightly. When a team is going to estimate a similar story that the team did in the past, it should use its estimate as a reference, learn how accurate was it, and then estimate the current story accordingly. Eventually, it leads to more accurate estimates.

2. Don't Vote

During the voting, product owners, product managers, and key stakeholders should not vote. They can bring some contribution, but they are not the ones going to develop the product. Moreover, their major emphasis is on completing the product by a certain time, so they can manipulate the discussion and estimation session unintentionally. Therefore, they should be restricted to just observe the discussions and voting to ensure that things go smoothly. However, they do can contribute when they think that the estimation is small or very large.

3. Tired Means No Estimates

There is always a hassle to complete a certain task even if you are feeling tired. When team members feel that they are tired of estimating stories due to a long session, they should stop the session and leave the remaining stories for another estimation session. Planning Poker is a fun activity and requires a full focus of members. Otherwise, when members try to forcefully complete the estimates, they are not at their best productivity level and it eventually results in inaccurate estimates. So, either stop or take a break when the team feels tired.

4. Practice Asynchronous Poker

Planning Poker requires that all the concerned team members join the estimation session, remain focused, and don't leave the room until all stories are estimated. But this whole process has some complications. For example, sometimes team members have to leave their important tasks or some team members might need more time to understand stories before estimation but hesitate to ask about it.

The solution to all these problems is using Asynchronous Poker or Async Poker. It is a modified form of Planning Poker in which members don't have to physically attend the session. The moderator (either product owner or Scrum Master) sends the stories to all the members and also mentions the deadline by which they have to respond back with estimates. This way, members are able to read and understand the stories at their own pace and provide estimates. After the deadline, the moderator receives all the estimates and checks if the team has reached the same estimate. If not, then a quick discussion session is carried out to reach the final team estimate.

5. Consecutive Sizes Issue

In a situation when a tie occurs in the voting for two sizes that are consecutive, then the team should pick the bigger size. The consecutive size could be 1 and 2, 3 and 5, 5 and 8, and so on if you are using the Fibonacci sequence. No team member should criticize this rule and should quickly move on to the next stories. It is because resolving tie issues usually take more time to resolve.

6. Avoid Technical Details

If the discussion around stories goes deep, teams should stop that discussion and quickly head for estimation. Sometimes members suddenly start discussing technical details that are ok for some cases, but not recommended on regular basis. There is a misconception that more discussion will lead to more accurate sizing, but that's not the case in reality. The easy approach is that people who are sizing should look for the simplest solution and pick a size accordingly. In fact, teams can even use timers to limit discussions.

7. Consistent Sizing with Iterations

From every iteration to iteration, the sizing should remain consistent. For example, if a team has set size 2 for one story, then it should remain consistent across all the remaining iterations. It implies that the team remembers its baseline. However, it is also fine if a team reevaluates the baseline after a few iterations to ensure that it remains in line with the current scenario.

8. Smart User Stories

The person that creates the user stories should try to meet development and QA leads prior to the estimation session to ensure that user stories address all the questions that the team is going to ask must. Later on, it will help the team members to only spend time on discussions around user stories not on gathering general information about stories.

9. Pick the Largest Size in the 3^rd Discussion Round

If a team struggles to reach a consensus even in the third round of discussion, then it should just pick the largest size. Doing so gives team members a chance to improve it without concerning that they haven't allotted the story enough time. Moreover, not giving proper time is more concerning than giving extra time. It releases the pressure and enables the team to focus rightly.

10. Let's Discuss It Later

When team members are discussing user stories and clarifying the requirements, saying words like “let's discuss it later” or “let's figure out later” is a big "No". For accurate estimates, a team should ensure that every doubt is addressed right away so that members can give the right sizing to the stories.

Final Words – Have Fun with Planning Poker

Planning Poker is a collaborative exercise meant to increase collaboration in a fun way. But most teams make it a tiresome activity, extending to 1-2 hours. However, it is always easy to come back to basics instead of grinding in the same phase. So, follow the above tips and tricks, enhance your Planning Poker estimation sessions, and make accurate estimates in a fun way.