Hi Brad,
I’ve just been invited to something called a planning poker meeting; what the heck is that?

Planning Poker is an activity that a team does to generate estimates for the activities that need to be accomplished by the team to satisfy the goals of the project.

The estimates generated during Planning Poker are Team estimates.

One of the problems that Planning Poker strives to solve is the reliance on a given person being the only one that can perform the given task; That is Task A which won’t be scheduled for another two weeks will be done by Bob and only by Bob and it doesn’t matter if Bob is over worked only Bob can do that task. In this reality Bob would give the estimate of how much time it will take Bob to do the task (since we know we’re going to give the task to Bob ahead of time) and now Bob is locked into that task. If two weeks go by and we find out that Bob is over worked and Sally is starved for work our options are to either accept it and fine something else for Sally to do or blow our estimates because all our estimates are Bob and Sally estimates and not Team Estimates.

By not electing who is going to do the work at some future time in our planning meeting that means we can remain flexible; the estimate generated in the planning meeting is the estimate that it would take anyone on the team to do the work (on average) that way anyone on the team can do the work. This will save your project estimates from taking a noise dive if say Bob got hit by a bus (or more pleasantly stated as, Bob won the lottery). So Bob is no longer available to do the work we estimated on, sad as it is I liked Bob, but that is OK because I wasn’t banking on Bob doing the work I was banking on my Team doing the work.

How does Planning Poker do this?

Planning Poker does this by use of Planning Poker Cards.

The Planning Poker cards are a special set of cards where the numbers on the cards represent Story Points (the weighting of the Story Points are defined by the team, teams I’ve worked on have made them one-to-one with days). I’ve heard of two different types of Planning Poker Cards:

Fibonacci-ish Deck

The Fibonacci-ish style Planning Poker Deck has 13 cards where each card has a number representing an amount in Story Points.

The cards are as follows: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Break

The Break (or as teams I’ve worked on have called it the Bio-Break) card is drawn when a team member feels that we’ve been at it to long and needs to recharge (use the rest room, get a coffee, just walk away for a moment to unfrazzle the brain or stretch the legs). I’ve been in planning poker meetings that ran hours (3-4 to be precise) these meetings are way to long and understandable why the bio-break card was drawn a few times. If your using Planning Poker meetings as part of Scrum then you should only be estimating the work slotted for the next sprint (this would be done in the Backlog Grooming meeting in preparation for the next Sprint Planning meeting). This should be achievable in 1 – 1.5 hours therefore eliminating the need for this card. If you require more time maybe the planning poker meeting should be time-boxed and broken up into multiple 1 hour meetings spread out so that your team members can spend some time doing the work of the current sprint vs. sitting in monolithic marathon meetings.

The Question Mark card is drawn when even after all the discussion some members of the team still does not have enough information to place an estimate. This card shouldn’t be drawn very often either as there should be some discussion before the vote and any team members not ready to vote should speak up before the vote negating the need to draw this card. But when it does it might indicate that your User Story isn’t ready and should be moved to next sprint.

Cards 0 through 100 each represent an amount of Story Points; The team member will draw which ever one of these cards they believe is the amount of effort it will take to complete the task in question. The key here is that they are not stating how log it will take Bob, our resident expert on this task, to do the work but how long it will take them to do the work. Bob will probably pick a lower number but that is OK it only shows that there are some knowledge gaps among the team that need to be closed. Maybe even though it will take longer the team might choose to let someone else other then Bob do this task so we can start building up more experts in it.

XS,S,M,L,XL Deck

The deck includes only 5 cards (or less) representing relative amount of effort. That is if Task A is estimated Medium and Task B is estimated Large then Task B is going to take more effort then Task A. That may be all the level of detail the Product Owner needs to prioritize the tasks. This can simplify estimations because your not sitting there trying to guess if this task will take 3 days or 4 days but rather asking if compared to all the other tasks already estimated how much effort will this task take; will it take more effort then Task A but less effort then Task B?

This is not to say that this Planning Poker deck no longer use Story Points; Story points are necessary for calculating how much effort a team can take on in a sprint and how to track its progress in attending higher levels of performance. Each card is associated with a Story Point, a small might be 2 and a medium card might be a 5 where a large might be a 13. In the meeting team members ignore the numbers and just focus on the relative amount of effort between tasks.

I’ve not used this form of Planning Poker personally say for one instance. In our first planning meeting we had just introduced Scrum to the team and product owner and didn’t have any User Stories (say for Epics). In that meeting we took the first few requested epics and started to break them down into User Stories. We did this in the meeting by writing them down onto sticky notes and placing them on a bare wall in the meeting room. As we estimated (using the Fibonacci-ish deck of Planning Poker cards) we moved the sticky notes around on the wall so that they were relative to each other from less amount of effort to most amount of effort. At some points when we were having trouble coming to consensus on a number the ScrumMaster simply picked up the sticky note and started walking up and down the wall asking if it was more effort then Task A but less effort then Task B until we found its home then picked a number that put it there. We could have simply used the XS,S,M,L,XL planning poker deck to get the same result.

Who Estimates?

Each Pig, that is each person who is responsible for doing the work, gets a deck of planning poker cards. The task up for estimation will be read out, all the Pigs, and even any Chickens in attendance can ask questions about the meaning of the task if there is any uncertainty (if the Product Owner is in the room, which is highly recommended, the task (i.e. User Story) can be modified for clarity). Once everyone is satisfied and ready to give their own personal estimate on the task each member picks a card from the deck.

All team members should estimate for themselves, how long will this take me to do, which is no different then what we did to poor Bob above, they also need to keep there vote secret until the Reveal. By not sharing your vote before all other members have had a chance to pick their vote you are not weighting their decision. They might have chosen differently but if you said “I don’t know about you guy’s but I think this is easy, probably a 3” then you’ll find a lot of 3’s popping up during the reveal. The problem is it might actually be a 5 but your statement influenced the vote down to a 3. By allowing a blind vote you get a much more honest answer.

Once the Vote has been revealed if the Team has collectively chosen the same number of Story Points then that is the estimate, mark it down and move on to the next User Story. If however there is a large divergent between the highs and the lows its time for a discussion. Both the team members who choose the highest and the lowest get the floor to make their case; why did they vote the way they did, did they see something others might have missed? Try to not let the discussion turn into a fight for supremacy, let the parties make their case, and any one else for that matter even the middle of the crowed voters if the conversion sparked an idea in them, then call for another vote. You can have as many rounds of this as needed but I suggest that you put a limit on them, say 2-3 rounds (including the very first round) max. If the divergence it still to large to call then the User Story might not be clear enough in which case it should be re-crafted (the Product Owner should be in the room and participating in the conversation) or its not ready yet (still to many unknowns) and should be moved to the next planning meeting. If the difference between the highs and lows are only off by a relative small number of Story Points the medium value should just be taken. Remember estimates are inherently inaccurate, if the spread is between 2-5 just take 3 and move on. An estimate is better then no estimate and you don’t want to keep the team members stuck in a planing meetings all day ~ Working Software over Comprehensive Documentation and all that as it were.

What Exactly are We Estimating?

Your estimating effort, not time.
If a task is really quick but has to sit in a third party queue for three days before finishing then the estimate is the amount of effort it take the team to complete the task; so since those three days are out side the team they are not included (i.e. the estimate could be a ½ or a 1 in this case).

Ok but Who’s Effort?

The teams effort; your team is cross functional, that is you have team members from development, QA, UX maybe, technical writers, etc. They are all members of the team so its their effort. If a task requires some software development then it must have QA activities assigned to it too and maybe even some technical writers work for the verbiage. That means at least three different team members need to work on this task and it won’t be Done-Done until all three team members completed their part of the work. So your estimating the total amount of effort that it will take all three team members to do in order to complete the task (ready for shipping).

Wait estimate QA’s time? That’s right you can’t ship the product until QA is done with it so why would you not include their effort. If the Product Owner takes all your estimates and tallies them up and that number tells them they can ship in June they will plan for a June launch. If your not including QA, UX, technical writers time then your estimates of off by a large among (might not see that product actually ship until December).

Another reason why the estimate should include more then just development time is because it sheds light on how much time it does take to QA things. There could be a User Story that seems trivial and the developers can write it up within 1 Story Point but the amount of permutations that feature has might make the testing take 8 Story Points. The Product Owner only cares about when they can ship, they don’t care that it only took 1 Story Point to write it if they can’t ship until QA is done. The task is effectively a 9 Story Point activity and that might not work for them so they will push it off as a lower priority item. This also lets the development team members know that some task that look easy take a large amount of time to test and the conversation on how the developers can help to speed up testing can begin, what if I add some hooks in the code for you guys will that speed up your testing time?

One team I worked on which I think did this rather successfully had QA in the planning meeting and had them also provide a vote (they are Pigs so they got cards). All voters were instructed to include design, review, unit tests, code writing, and manual QA test effort in their vote. Yup QA estimated how long it would take to not only run the test but to write the code and visa vera developers estimated how long they thought the testing would take. Sure the numbers didn’t always match up but if the developers estimated high because they thought it sounded like a lot of manual testing and QA estimated low because they knew it was actually an easy thing to test well that was simply said in the discussion and round two showed a much tighter spread. The benefit is that all members of the team regardless of their function start to learn a bit more about how much effort it really takes to truly complete a User Story – Transparency.

So that is what the heck Planning Poker is, an activity that a team does to generate team level estimates for the activities that need to be accomplished to satisfy the goals of the project. If you have a different view or have any comments or questions feel free to leave them below and I’ll try to answer them as time permits.

Until next time think imaginatively and design creatively