Summary

 

 

Motley: Wideband Delphi is overkill for smaller tasks. I would never invite a bunch of people to an estimation session to estimate a 20 hour task.

 

Maven: Planning Poker is a lighter variant of Wideband Delphi that provides similar benefits to Wideband Delphi but more efficiently.

______________________________

 

[Context:  Maven and Motley are having a continuing conversation around estimation techniques]

 

Motley: As I was saying, Wideband Delphi (WBD) is definitely overkill for smaller tasks. I don't want to get a bunch of people in a room for an arranged meeting and go through an interactive exercise for a small 20-hour task!

 

Maven: I agree with you.

 

Motley: What?!? Seriously??

 

Maven: As shocking as that sounds, yes. One technique we can leverage for smaller tasks is Planning Poker. It follows the same basic recipe that WBD does, except that the process is more lightweight and meant for quicker estimation.

 

Motley: I get the same benefits as Wideband Delphi but it's more lightweight and quicker? Sold! Forget the WBD stuff - why didn't you tell me about Planning Poker sooner??? I'd love to put my card playing skills to the test!

 

Maven: Hold on! Don't jump to conclusions. WBD is the recommended technique early in a project where there are many unknowns and you are estimating larger tasks for the purposes of overall scheduling. Tracking the team decisions also allows you to go back and justify your initial estimates and refine specific pieces as you remove variability from the project. Still much value there. Use Planning Poker for smaller tasks with fewer unknowns.

 

Motley: Well quit beating around the bush - what's the technique already??!?

 

Maven: Ok, ok. Patience is not one of your virtues! Anyway, first you need to get some people together for the Planning Poker session. Usually in a session like this you'll have a set of work items that you want to estimate. Each person comes with a set of cards that are used for estimation. The content of those cards is some sequence of numbers in hours. A good sequence to use is 1, 2, 4, 8, 16, 32, and 64. My team usually throws in 48 as well. Other sequences I have seen used include 1, 2, 3, 5, 8, 13, 21, 34, and 55. Know what sequence that is?

 

Motley: I know, I know! It's the-

 

Maven: Ah, let's leave it to the others to tell us. [Ed: Let us know in a comment below]

 

Motley: So what's the point of the cards? Just because someone called it Planning Poker I bet!

 

Maven: The cards constrain the estimates to keep things moving. Here is the overall process:

  1. The originator of the work item gives the group a very brief overview of the work involved. A sentence or two description is usually sufficient.
  2. Take a small amount of time (30 seconds to 1 minute) to think over the assumptions that go into the task. No need to write them down - just keep them in your head.
  3. Pull out the card that most accurately represents your estimate. Keep it upside down until everyone is ready.
  4. Everyone shows their cards at the same time.
    1. If the numbers are identical or very close, the group decides on the number and moves to the next task.
    2. If the numbers differ, a discussion ensues focusing on the owners of the outlying estimates. Why are the estimates different? As with WBD, make some team decisions about assumptions. Do the process again with each person once again showing a card corresponding to their estimate  and continue the process until the numbers converge.
  1.  

 

Motley: Some differences I noticed: estimates are no longer anonymous, estimates are fixed, and we don't capture team assumptions in writing. In addition, just because everyone shows the same number does not mean they have the same assumptions about the task! This technique, although quicker, is flawed!

 

Maven: Estimates are not anonymous as the tasks are much smaller, so variance is not as large and participants can still go with their gut with little pressure. Yes, estimates are fixed as a guideline, but if half the group chooses 8 and half chooses 16, a compromise of 12 is certainly valid. We don't capture team assumptions in writing to keep things efficient, and because the tasks are such fine granularity anyway. Your last point is certainly valid, however. There is a risk that assumptions differ but numbers are the same. That's a risk our team is usually willing to take for efficiency, and because the penalty on small tasks like this is not large. Often we have a small conversation even if the numbers are the same to ensure we are on the same page.

 

Motley: Sounds pretty cool. I'd be willing to give it a shot in our next planning meeting. Since the technique has "Poker" in the name, I vote that everyone contributes $5 to a central pot and we track everyone's initial estimates. At the end of the iteration we see how many people were within 10% of the actual number and the one with the most accurate estimates wins the pot!

 

Maven: Ugh. Whatever suits your fancy, Mr. "My main value in life is money." Just promise me you won't start making "Royal Flush" jokes.

 

Motley: Well, there once was this king who ate Mexican food the night before and had some really bad gas the next day-

 

Maven: Enough! I'm going to, errrr, write some code. Remember to use WBD and Planning Poker as necessary. The collaborative technique  will improve the accuracy of your estimates - money back guarantee!

______________________________

 

Maven's Pointer:  Don't go crazy creating fancy cards. On the Xbox team, during every sprint planning session we use index cards with hand-written numbers on them. You can also use Post-It notes or whatever else is handy to create cards on-the-fly. Planning Poker is a great agile technique that you can use to estimate the work in your monthly or weekly iterations.

 

Maven's Resources: 

  • Agile Estimating and Planning, by Mike Cohn, Prentice Hall PTR, ISBN: 0131479415, November 2005.
  • http://www.planningpoker.com - a free online tool that your team can use for a planning poker session. No need to create cards! Also great for a session among distributed teams.