Feb 11, 2009

Planning Poker Without the Cards

One of the recommended practices when doing agile software development is to get estimates from each of the individuals in the team without having them influence each others thinking.  That way you get multiple points of view on an item and avoid the issues of having one person estimate on behalf of everyone else in the team.  You also foster greater communication amongst those estimating and greater collective ownership of the estimates themselves.

Another recommendation is to use relative estimating and banding/bucketing of estimates.  Relative estimation is just a matter of estimating the size of one job compared to another.  Doing so makes it easy to understand the relative difference between an estimate of 1 and 2 but the relative difference between a 28 and 29? Who cares – it’s so small it doesn’t really matter.  For that reason the use of banding is encouraged to avoid wasting time trying to get the perfect estimate.  An estimate is what it is – an estimate.

Enter Planning PokerPlanning Poker is a very simple process that helps teams estimate using the above recommendations and works as follows:

  1. Everyone on the team is given a deck of cards.  Cards contain valid estimate numbers, typically something like 0,1,2,3,5,8,13,21,40,100,200 & ?. (The “?” is when you are unable to estimate)
  2. As each item comes up for estimation the team asks enough questions to get a reasonable idea of what’s involved so they can each make a valid estimate.
  3. Each individual selects from their deck a card that matches their size estimate and either puts it face down on the table or holds it up against their chest or forehead (face hidden) to indicate that they have made an estimate.
  4. When everyone is ready all team members show their estimates at the same time.
  5. If the estimates are within one banding of each other the high number is chosen as the estimate.  i.e. if everyone selected a 5 or an 8, then the estimate is 8.
  6. If the estimates differ markedly then the people who made the lowest and highest estimates defend their reasoning.  Once that reasoning is understood, the process repeats from step 3, until a consensus is reached.

All pretty simple, right?  Well it is, until you try to do it in practice.  I’ve found that a lot of teams find the idea of playing with cards during work hours just a little too geeky and it makes the adoption of the planning poker process a little harder than it should be.  Oh yeah, and you also need to make sure you have a deck of cards for everyone in the team.

To make adoption a little easier I use a “rock, paper, scissors” style of planning poker. I make sure the team know the valid numbers they can choose from for estimating and then do all the same steps as for normal planning poker, but instead of holding up a card to indicate they are ready, they just hold two fists out  (or put them on the table) to indicate they have an idea in mind.

Once everyone is ready it’s then just a case of saying “1, 2, 3, go” to get everyone showing their estimates at the same time.  The number of fingers held up indicates the estimate.  For numbers above ten, e.g. 21, people would show two fingers on the right hand and one on the left.  Simple enough.

The advantages? It feels less geeky than using cards, you don’t have to ensure everyone has a deck of cards to start with, and you don’t have to watch people fumble around getting the card they need to choose for the estimate.

6 comments:

  1. One of the biggest areas of confusion i've experienced with dev teams is what are you actually estimating on? Yes it's relative, but relative in terms of what?

    The unit of measurement had varied from one team to another. Some teams estimated based on the gut-feel of effort required, others estimated based on how long they thought it would take, and one team estimated based on both!

    i'm interested to know what your team uses when estimating size in planning poker?

    ReplyDelete
  2. Relative sizing is simply the sizing of one story/requirement relative to the others, there is no unit of measure - it's just an estimate of the effort required between stories.

    However you can't do relative sizing against nothing, you need a baseline.

    So, to start I'll get the team to pick a few stories that they think are around the 2-3 day mark to do. Those get given a size of '2'.

    Next they try and find a few stories that are about half the effort of those '2's. Unsurprisingly they get size of '1'.

    Then they look for some that are about half as big again as the '2's and make them '3's.

    At that point the team has a feel for how sizing works, and what the baseline is for comparison. From there, it's just a matter of working through the rest of the items.

    ReplyDelete
  3. yah - you answered my question in your first sentence: "it's just an estimate of the **effort** required between stories"

    :)

    The next question is, how do you explain "effort"? How do you introduce a new team member to the definition of "effort"?

    ReplyDelete
  4. How does, "get[ting] estimates from each of the individuals in the team without having them influence each others thinking" do this, "foster greater communication amongst those estimating and greater collective ownership of the estimates themselves"?

    ReplyDelete
  5. @liam, by ensuring no-one reveals their estimates ahead of anyone else you don't get the situation where the team members watch the team lead or senior/noisy dev for the estimate to provide. Everyone needs to think for themselves because they can't just point at someone else and say "what they said".

    The greater communication comes because the high/low end estimators get to speak about why they think the way they do and discussion typically follows. It will also mean that people on the team who wouldn't normally speak will have to.

    The ownership comes because the estimate reached is a consensus estimate for which everyone is responsible for providing, not just one persons estimate that everyone else has to live with.

    ReplyDelete
  6. I have used planning poker on my last three development projects.

    These projects have ranged from relatively small (several people several months) to incredibly large (9-20 over a year).

    On the really large case, three different senior architects had to put estimates together using three different methods. Two of the methods were extremely complex with the really detailed spreadsheets and lots of detailed formulas etc.

    I was one of the three, and used planning poker with a team of four people, and took half a day to do the estimates while the rest of the people took two weeks.

    All of our estimates were within 20% of each other.

    I think this lets planning poker speak for itself. It's effective, and it works.

    Jeff
    http://agileconsulting.blogspot.com

    ReplyDelete