A Look at Planning Poker
A Look at Planning Poker
Join the DZone community and get the full member experience.Join For Free
Engineers build business. See why software teams at Atlassian, PayPal, TripAdvisor, Adobe, and more use GitPrime to be more data-driven. Request a demo today.
Planning Poker (AKA the Grenning game) is a relatively popular agile tool for making estimates on a project. Each team member is handed the same set of cards with numbers representing units of work, and "play" his/her estimate on the time needed to implement a feature or a story. Each team member makes an estimate by choosing the corresponding card and laying it face down, as that card must not be seen by the other team members until the end of the round where all cards are exposed by turning them over. Then a short (timed) debate can start to reach a consensus (or not) on what would be the best estimate.
Some important points to consider in order for the tool to be effective:
- There needs to be cards other than containing numbers. Why? Because you cannot always estimate with confidence. You might not understand enough about the feature to give an estimate (card with a Question Mark), or you might think that the implementation will take much longer than planned (card with an Infinity Sign), or...you just need a break at this point (card with a Coffee Cup).
- The numbers on the cards must have a difference in magnitude. Having a set of cards such as 0,1,2,3,4,5,6 will have people bicker over whether it will take 4 or 5 days (for example) to implement a particular feature. You really don't want that. You want to have meaningful changes in magnitude for one card (one estimate) to the next. A popular way to do just that is to use a Fibonacci Sequence: : 0, 1, 2, 3, 5, 8, 13...., although some will use other types of sequence, like 0,2,4,8... BTW, zero should be included as a number in case the feature that can be implemented in no time or...is already implemented.
- The set of cards must be small. High numbers provide little value because high estimates mean that the story is not well understood, or that it can be broken down into multiple smaller items. Large estimates give a false sense of security, and can always be split into smaller chunks which can each be estimated more accurately.
Great, so now we're playing cards at work. We could see the fun, but where's the value? Why not just discuss estimates openly?
Mainly to prevent Anchoring.
An open discussion on the matter puts forward the influential members of the team with their personal agendas and opinions. The other members will then tend to base their predictions more or less consciously on the number (anchor) given previously by the influential member(s). Those who had a lower or higher number in mind might revise their initial estimate to be more in sync with the number given initially by the dominant members of the team.
With Planning Poker, when all the cards are turned over and compared, gaps in estimates are where things get interesting. For example, if a developer has chosen a number deviating significantly from the group average, a discussion can take place. Maybe that developer didn't understand the story, or... maybe he understood it better than the rest of the team. Estimates are less about predictions and getting the numbers right than common understanding, commitment and delivering value.
There are some fun variants of Planning Poker, like Fruit Estimation Poker, where the Fibonacci numbers on the cards are replaced by...images of fruit. It goes from smaller fruits to bigger ones, like from Cherry (smallest estimate) to Melon (large estimate, please slice).
Planning Poker and its variants are a fun way to make estimates, trigger interesting discussions and arrive at a common understanding of what needs to be done. The downside, as a side effect is the drift to Cargo Cult engineering. I'll spare the reader Yet Another Good Agile vs. Bad Agile discussion, as there are already many excellent articles on the subject. Planning Poker is not a science, with averages and standard deviations, where you should be obsessed with getting the estimates right. Rather, it is one method among others, to help fight assumptions and uncertainties. Be adaptive. As with any other Agile (or non-Agile) tool, use it for what it is and for as long as it delivers value, drop it if it stops working for you and switch to something better.
Opinions expressed by DZone contributors are their own.