Think it's difficult to make accurate time estimates? You're not alone. In this article, you'll learn how to use the planning poker technique. Planning poker is an effective and fun way to estimate how much time is needed for various development activities.

It's easy to start using planning poker. First, you'll need a deck of cards for each person who is going to participate in the planning exercise; you can buy card decks on the Internet. The cards are printed with numbers that correspond to various development times: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and "Don't know." For simplicity, the numbers on the cards can be translated as "number of days," but in agile development, more sophisticated time scales are often applied.

The planning poker activity begins when you assemble the group—typically the development team—to make time estimates for a number of requirements. Someone starts by choosing a requirement and describing it to the group. After a period of discussion and consideration, each member of the group estimates the time he thinks will be needed to accomplish it and chooses the card from his deck that best describes the estimated time. The participants lay their cards face down and, when everyone has chosen a card, all the cards are turned face up. The group discusses any differences and, if needed, starts the process again. Usually, after a few iterations, the group will agree on a reasonable time estimate.

A common problem in classical time estimation is that it's easy to "plant" an idea or view that becomes the default estimate. If you ask a group, "How long will it take to complete this task?" and the first person answers "forty hours," then the rest of the group will consciously or unconsciously begin to relate to the number forty in their time estimates. In fact, it's highly likely that the group's answer will be near forty hours, even though some participants may initially have had a completely different view. People who have a different opinion don't always speak their minds in front of a group for fear of being wrong. Planning poker solves this problem by allowing each participant in the group to make his time estimate privately and then forcing the group to discuss the rationale behind the most divergent time estimates.

Another advantage of planning poker is that all members of the development group (for example, developers, testers, and users) contribute to the time estimate, instead of letting just one specialist do the assessment himself. The basic idea is comparable to a workshop: A group's results are better than an individual's, owing to the synergies that arise when the group discusses and debates assumptions and collectively tries to reach consensus. A group decision also ensures that time estimates aren't too overly optimistic. If you ask the best developer to estimate the time required for a task, the estimate will be based on how long the task would take the developer to do alone, not how much time it would take an average team member.

Figure 1: A recent planning poker activity used during sprint planning at the offices of ReQtest.

Benefits of Planning Poker

So, in the end, what are the benefits of planning poker? For a start, each participant gets the opportunity to think in silence, reducing the risk that ideas gets "planted" by other group members. Secondly, all group members get involved in estimating time, whereas discussing requirements without the card deck runs the risk that some participants won't actively participate. Time estimates are based on group consensus rather than an individual's opinions, thus increasing buy-in by the entire team.

Additionally, planning poker fosters a deep discussion of the reasons for various time estimates, ultimately leading to better knowledge among the participants. The approach is iterative because you can repeat it in several small exercises, and it's a fun way to estimate time because it encourages creativity, competitive spirit, and commitment to the team's tasks.

Finally, when using planning poker, the team more or less automatically comes to a common understanding of the definition of "done," and this common understanding is crucial during development.

Disadvantages of Planning Poker

What about the disadvantages of planning poker? It is true that the technique can be difficult to implement in distributed projects, where participants don't sit together in the same office. However, there are web-based tools that can be used when the working group is distributed.

The results from planning poker exercises can also be a little too hot to handle. For example, if it transpires that you need more time than the client has anticipated, you may need to change your priorities in the project plan. Any change in priorities requires buy-in from the client.

Finally, there's always a danger that you believe you have consensus, when all you really have is insufficient information to make an accurate assessment.

In Conclusion

As with any other technique, planning poker is extremely helpful and useful if carried out correctly. Start small and see what results you get before you attempt to go really big. Ensure that your team knows what behaviors can ruin the point of planning poker, and make sure that they try to curtail these for the duration of the exercise.