Scrum poker is the new go-to tool for estimation of agile projects used by many agile teams nowadays. But it is also used in the wrong way. Different people play different variations of the planning poker game. Some variations are effective and some prove to be meaningless. So less discuss a few tips and tricks that can make a meaningless game into an effective practice.
Tip#1: Do not compare work hours with story points
Given that technically inclined people have a natural desire to make sense of things through reasoning, teams that are new to Agile development frequently want to quantify everything. Instead of relative size of work that takes into account the impact, difficulty, and degree of understanding of the task, employing units of work hours in this context is a lot simpler notion to understand. Teams that use formulas, such as 7 hours per user story point, frequently fail to see the significance of relative estimates, which is to quickly get a high-level grasp of the job.
Tip#2: Discipline the estimation process and avoid group think
A lot of agile teams get quite sloppy with the Planning Poker process because it feels more like a game than a serious method to accomplishing important work. Perhaps having playing cards in your hand inherently disarms individuals. While it’s OK to keep things somewhat informal, it’s crucial to oversee the process and make sure that the team is making the most effective use of their time. The idea of “group think,” which refers to the phenomenon where people passively accept the views of a larger group in order to avoid confrontation, even if their perspective varies from the majority of the group, is one important danger to avoid.
Tip#3: Avoid personalising the game too much
A lot of teams often modify the Planning Poker game’s poker cards, choosing particular cards that they believe make sense to use for a particular sprint. It is better to settle on a series, such as the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) or a modified version (1, 2, 3, 5, 8, 13, 20), and stay with it. Changes to the series should only be made with the Agile Coach’s approval and a valid cause. Some teams include a “?” card so that team members can mention the need for further information. Due to the possibility of misuse, it is suggested to be used sparingly.
Tip#4: Make sure the right stakeholders take part in the Planning Poker process
A number of teams want to minimise the number of people involved in the planning process, because they believe that only those with the great expertise fully comprehend the product or system to be able to produce an accurate estimate. This line of reasoning is inherently wrong, because the relative estimating procedure is not meant to produce an exact estimate. Teams that restrict participation to a small part of the overall team are basically missing out on the knowledge and skills of those team members who are not actively participating. The effects of this can be far worse than one might anticipate, ranging from incorrect estimations to a decline in team spirit.
Like many other Agile development techniques, the Planning Poker estimating approach is one that is “simple to learn, but hard to master.” You can help your teams to get the most out of this technology by keeping an eye out for possible problems.
Blog 