Planning Poker - A Great Estimating Tool!

By Chris Davies, DSDM Member | 13 October 2015

The problem with traditional forms of estimating work, especially software development and testing, is that we often get the 'expert' to do it. There is a fundamental problem with this - the expert will naturally estimate how long it will take him to complete the work, which is almost certain to be quicker than anyone else who isn't an expert, meaning all the work is under-estimated, and no-one else understands the assumed technical solution. Related to this is that, if just one person provides all the estimates, the people doing the work won't feel any real obligation to meet those estimates ("I didn't say I could do it in 3 days").

Planning Poker is a form of group estimating, which also solves a common problem with other group estimating techniques - that of influence. The first estimate in a group is likely to influence other people in the group. Planning poker solves this problem using the cards. Another advantage to this technique is that it provides an opportunity for everyone to discuss each requirement that isn't clear to everyone, ensuring good collective understanding of all requirements. This saves a lot of time later on. So how does it work? It is important that not just the developers contribute to estimates. Include anyone who will contribute to getting the work completed, including business people, analysts and testers. All opinions are valid. Each estimator gets a set of about 12 or 13 cards of the same colour (there are 4 of these sets in each pack of planning poker cards. For the first requirement to be estimated, I would suggest selecting the smallest one identified so far (I have sometimes found it easier to pre-sort all the requirements into Small, Medium and Large beforehand). Assign this small story a value of 1 (still leaving 1/2 and 0 for even smaller ones if they arise later). The process then proceeds as follows until all requirements have been estimated:

  1. The Business Ambassador selects the next story and reads it aloud to everyone.
  2. Estimators can then ask questions of the Business Ambassador to better understand the requirement. At this stage there should be no discussion of the solution; just the requirement. Try to limit this step to a couple of minutes.
  3. Time to estimate. Each estimator selects the card in his/her hand which represents the size or weight of the effort to complete the solution to this requirement, relative to the others. This is not an absolute measurement; it is just a relative measure. Place the card face down on the table. This ensures no one else is influenced by your estimate.
  4. When everyone has placed their cards on the table, everyone turns over their cards to reveal their estimates. If the requirements are fairly well understood, the estimates should be clustered in a fairly small range - say 2,3,5 but this is not always the case.
  5. The facilitator should then ask those with the lowest and highest estimates to explain the reasons for their estimates. It is possible one person has thought of risks or complexities no one else has. It is just as possible that someone has thought of a simpler, quicker solution than everyone else. Allow a little time for discussion, but again don't spend too much time.
  6. Then repeat steps 3 to 5. By now, provided the requirements are well understood, everyone should now be estimating within one number of each other. If so, select the higher number and move on to the next card. If not, you could go through one more round of estimation, or it may just mean that more technical investigation is required. In this case, ask if we could add on a little to account for complexity and move on. This process is repeated until all the story cards have been discussed and the estimates recorded on each story card. Remember, it is just an estimate and does not have to be precise. Spend only as much time estimating as the value you will get from the estimates themselves. The discussions of each requirement and the shared understanding generated is actually the more important factor. Kindly supplied by Chris Davies, Agile Consultant and DSDM Practitioner and Trainer
Tagged in