# Estimate Time and Set Priorities with Planning Poker

[article]
Summary:
Estimating time for software development in groups can be tricky. The first person's response often plants an idea in the heads of the rest of the group, leading to an incorrect estimate. One way of getting around this is to play a few rounds of planning poker.

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