More about Planning Poker

In the last post, we discussed the planning poker as one of the famous agile estimation techniques. Let’s dig into more details about that estimation technique. When using this technique, we have to consider the following:

• This technique is consensus-driven approach and not voting, so don’t take the estimation of the majority as the final estimation of the user story.
• Estimate some few user stories at the beginning to make them as a baseline or reference for the team’s estimation is a good practice. It makes the estimation process easier, faster.
• Don’t take the average of the estimations given by the estimators. The team has to discuss the divergence in the estimations in consecutive estimation rounds until reaching the consensus.
• The scrum master (the estimation session’s facilitator) picks up a punch of cards and estimates as any other team member.
• To avoid being affected by others’ judgment or estimations, the estimation should be done privately and the cards turned over and revealed at the same time. For instance, usually the team members can easily be influenced by the estimations of the seniors or the more experienced members, so keeping the estimation private will protect against this kind of personal influence.
• If one of the team members thinks that the estimation of a user story is a number between two Fibonacci numbers, ask him to round his estimation up to the nearest number in the Fibonacci series. Let’s say he thinks that a user story deserves 6 or 7 points, so he will round up his estimation to 8 points for that user story.
• Remember: This is a high-level estimation, so don’t try to spend much time fine-tuning its accuracy. Investing more time in this fine-tuning won’t improve the accuracy of the estimation as depicted in the following graph (Source: Agile Estimating and Planning Book by Mike Cohn).

This graph clearly shows that beyond a certain point of effort the accuracy does not improve rather it goes worst.

The right time to play planning poker

If we realized the ultimate value gained from the planning poker, most probably we will be able to play it at the right time that maximizes its benefit.

Basically we do this kind of high level story points-based estimation for two mean reasons as follows:

• Help the business representative (The product owner) to prioritize the product backlog items (user stories) by weighing the business value of the user story or the feature versus the cost of make it done. The cost here means simply the estimate given by the delivery team.
• Help planning the product releases and setting the long-term expectations about the delivery dates and the set of features could be delivered. Simply, to answer popular questions raised by the business such as how much work or features could be delivered by a certain date; we have to size the work to be performed to make those features done.

Keeping the above reasons in mind, there are two times in the project life cycle that would be the best time to play planning poker:

• After the user story writing workshops: Usually after this kind of sessions we have a big number of user stories to be estimated and this will be the right time to do the estimation, so the product owner will have the enough time to prioritize the user stories. This workshop will be done usually on quarterly basis.
• During the product backlog grooming meeting:

The backlog grooming (refinement) meeting is held near the end of the sprint to ensure the product backlog is ready to the next sprint. The product owner will be the key person in that meeting, and the whole team should be present. This means that the frequency of playing planning poker here is once per sprint.

The backlog grooming or refinement is a checkpoint existing in each sprint that gives the product owner an opportunity to gather and address any questions or issues related to the product backlog items. So it is a checkpoint rather than an effort to fully resolve issues or provide complete answers. This will give the delivery team the confidence that the product owner will be ready with the sufficient answers at the time of the next planning meeting of the next sprint.

A planning Poker Anti-Pattern

Playing planning poker at the sprint planning meeting is a bad practice and one of anti-patterns; for three main reasons:

• The team will spend too much time in the sprint planning meeting due to the extra effort needed for the estimation, so it is better to do this estimation effort on the user stories level before the next sprint planning meeting as mentioned earlier.
• The team in that planning meeting has to go deeper into details to estimate the effort and the tasks needed to complete the sprint backlog items in a more accurate manner, which is totally different context from the planning poker sessions that conduct the estimations around a high-level view.
• It will be late for the product owner to adjust the priorities or address any other issues related to the backlog items (user stories).