...
- Participants include all developers on the team.
- Each estimator is given a deck of cards.
- Each card has written on it one of the valid estimates.
- The cards should be prepared prior to the planning poker meeting.
- The numbers should be large enough to see across a table.
- For each user story or theme to be estimated, a moderator reads the description.
- The product owner answers any questions that the estimators have.
- The goal is a valuable estimate can be arrived at cheaply.
- After all questions are answered, each estimator selects a card representing his or her estimate.
- All cards are simultaneously turned over and shown so that all participants can see each estimate.
- If estimates differ, the high and low estimators explain their estimates.
...
- A constructive conversation here is extremely valuable in arriving at an accurate estimate.
- After the discussion, each estimator re-estimates by selecting a card
...
- .
...
- In many cases, the estimates will already converge by the second round.
...
The Right Amount of Discussion
...
Some amount of preliminary design discussion is necessary and appropriate when estimating. However, spending too much time on design discussions sends a team too far up the effort/accuracy curve of Figure 6.1. Here's an effective way to encourage some amount of discussion but make sure that it doesn't go on too long.
Buy a two-minute sand timer, and place it in the middle of the table where planning poker is being played. Anyone in the meeting can turn the timer over at any time. When the sand runs out (in two minutes), the next round of cards is played. If agreement isn't reached, the discussion can continue. But someone can immediately turn the timer over, again limiting the discussion to two minutes. The timer rarely needs to be turned over more than twice. Over time this helps teams learn to estimate more rapidly.
...
When to Play Planning Poker
Teams need to decide when to play planning poker. Probably at the beginning of a project and then for the first couple of iterations. After that, the team may be comfortable with its estimates.
Why Planning Poker Works
...
Now that I've described planning poker, it's worth spending a moment on some of the reasons why it works so well.
First, planning poker brings together multiple expert opinions to do the estimating. Because these experts form a cross-functional team from all disciplines on a software project, they are better suited to the estimation task than anyone else. After completing a thorough review of the literature on software estimation, Jørgensen (2004) concluded that "the people most competent in solving the task should estimate it."
Second, a lively dialogue ensues during planning poker, and estimators are called upon by their peers to justify their estimates. This has been found to improve the accuracy of the estimate, especially on items with large amounts of uncertainty (Hagafors and Brehmer 1983). Being asked to justify estimates has also been shown to result in estimates that better compensate for missing information (Brenner et al. 1996). This is important on an agile project because the user stories being estimated are often intentionally vague.
Third, studies have shown that averaging individual estimates leads to better results (Hoest and Wohlin 1998) as do group discussions of estimates (Jørgensen and Moløkken 2002). Group discussion is the basis of planning poker, and those discussions lead to an averaging of sorts of the individual estimates.
Finally, planning poker works because it's fun.
...