Source: Wikipedia
Font: AndrewScript 1.6
Planning poker, trademarked by Mike Cohn, is a modernizing of a 50+-year-old estimating process known as Wideband Delphi. Estimating is not far from the dark arts, and attempts to make the process serious and exacting are ill advised. James Grenning devised planning poker as a quick and entertaining way to come to consensus on estimating stories in agile. I've found it can help dramatically minimize the tedium of estimating through a large stack of stories.
A typical point scale might be 1, 2, 3, 5, 8, 13. Resist larger scales--toss the higher-value cards. You might replace them with one card that says "too big."
You might want to include a few additional cards: 0, ? ("I don't have clue"), and infinity. The value of adding a 0 card is debatable (nothing is free, and even if development is "free," testing a story is never free), but you may find some usefulness in having it: Sometimes, completing one story automatically includes another. Or, a story might simply represent a milepost achieved.
The wikipedia site provides good detail on the steps involved, but I highly suggest you make your own rules and stick to them. The section on anchoring is particularly useful: part of the reason James devised planning poker was to counteract the heavy influence on estimates coming from one individual. Make sure that when people divulge their card selection, they aren't watching and waiting on certain other individuals to show theirs first!
Before starting the meeting, figure out how long you'd like to spend estimating. If your backlog of stories looks pretty good, and there's a good understanding of the project by most people in the room (obviously not always the case), you might find that 5 minutes per story works well. Appoint a facilitator who can keep time and help keep the estimating session on track.
If the product you're building is less well-known to the participants, this process will take considerably longer, maybe 10-15 minutes per story. Do the planning poker estimates, regardless, and plan on doing them again during a quicker second meeting. If you feel like you are bogging down on a story, and understanding of it is not "critical path," set it aside, and plan to come back to it after other stories are visited.
For a backlog of not-well-understood stories, you will probably want a couple sessions. Some stories will need to be set aside to split or researched offline. Some stories will need to be revisited by the customer. One of the best things to do is give people time to go off and think about things (and having at least one night between sessions is always a good idea).
Still, you want to avoid investing too much time in estimation. The more time you invest, the higher the expectation that the numbers coming out of it are anywhere near perfect. Estimates are guesses!
Instead, the estimation meeting is best seen as a way to ensure that we have good, appropriately sized stories that are fairly well understood by everyone involved. The consensus mechanism in planning poker will quickly let you know if this is not the case. Getting confidence from a good ballpark project plan is almost a bonus!
Why not using the "tool in hand"?
ReplyDeletefist-to-five (count the fingers raised, fist=0).
No preparations necessary, no "I forgot my cards", ....
With cards, you select your answer and lay the card face down on the table. When everyone has chosen, you flip them over. There is selection first, and you show what you've selected.
ReplyDeleteWith fingers, you are all choosing and showing at once, and a very short lag allows you to parrot anyone you don't want to disagree with.
The point of this is to get everyone's honest assessment and to avoid both campaigning and contamination. The goal is to get the truest consensus as simply and quickly as possible.
BTW: I've seen one guy arguing about how simple a change should be (to keep the other from inflating) and another argue how hard it was (to keep the other from trivializing) when in fact they were both thinking "three". I've also seen the most outspoken members of the team be entirely wrong, for reasons that the most timid understood well.
As far as displaying your answer, fingers work. As far as making sure you've chosen before you see the other people's answers, it fails as often as not.
Using cards also makes this feel more like a game, which for many participants (not all) helps keep it enjoyable.
ReplyDeleteI've seen planning poker work in most places tried, but I've also encountered a couple teams that didn't care for it, which is fine--they can pick from one of the myriad other ways of estimating.