Ever heard of planning poker? If you haven't, continue reading. If you know what planning poker is and don't feel like reading yet another intro, jump over to The Beef. No, wait. I think you should read the whole thing. If for no other reason than to see where you and I differ in opinion or style. You might even be inspired to post a comment or a trackback or whatever folks nowadays do in the blogosphere.
Planning poker is a group estimation technique popularized by Mike Cohn. And it's focused around playing cards - hence the name. It's not really poker but you often see teams using a deck of playing cards just like the ones you use for ripping off your mates in Texas Hold'em. At gunpoint, I might identify one similarity between planning poker and hold'em, though. You don't know what cards are the other players holding.
Ok, enough with the mystery. Here's how it works.
You're in a planning meeting for the next iteration. You have a bunch of features to implement and you need to figure out which or how many of them you can implement in your two-week iteration. There's plenty of things you and your team needs to estimate and a limited amount of time to spend on it. Let's say you're using story points. So, you pull out a deck of cards.
You deal out sets of six cards (A,2,3,5,8,K) to each team member - everyone gets an Ace and a King and cards of rank 2, 3, 5 and 8. Next, you name the feature you're estimating and maybe read out loud some details such as a short description, the acceptance criteria, or something like that. A brief discussion ensues where team members ask clarifying questions about the feature. Then, one by one, the team members place their hand on the table, holding one of their cards face down. Once everyone has their hand (and card) on the table, you count to three and turn the cards over. The rank your card has expresses your estimate for whatever you're estimating. The Ace is a "1", the King is "too big to estimate". Everything else is just that - the rank.
Some teams find that plain old playing cards cramp their style and order specially designed planning poker cards from Mike Cohn, Crisp, Nordija or PlanningPokerCards.com. Or, if you're working with us, just ask and we'll bring along a couple of decks or our cards. Our cards are obviously better looking than the rest but they all work quite nicely.
As you look around the table and your team members' cards, you see one of three things: a consensus, numbers all over the range, or something in between. If there's a consensus you write down the estimate - you all agree so there's no point in going through motions. In any other case, the highest and lowest estimate explain the rationale behind their estimate - why did they give that particular estimate? A discussion ensues and, after some 53 seconds of exchanging thoughts, people start putting their hands on the table again - with a card face down, indicating that they're ready to have another go at estimating whatever you were just estimating. The odds are, you now either get consensus or don't. (Yes, I did figure that out on my own.) If you get consensus, write down the estimate and move on. If you don't, have another go at arguing for the high/low estimate and re-estimate. If you still don't get consensus (or near consensus), you either take the highest estimate or the average. It doesn't really matter all that much which approach you take - just decide the protocol with the team before the planning session.
There. You've got all the items estimated and there's still 12 minutes before someone takes over the meeting room. And, lo and behold, those estimates included not just the input of Jack and Bill who are always keen to voice their opinion about anything and everything but also that of Steve and Melinda who usually keep their mouth shut while Jack and Bill argue about effort estimates. This planning poker stuff isn't just fast and lightweight. It's also helping our team commit to its promises simply by involving the whole team in the estimation process!
That's planning poker. Simple. Fast. Effective. However, when people get introduced to planning poker and go about their first planning session using it, something happens that I really dislike. It has to do with what you do when you don't immediately get consensus. Let me explain.
The Beef [with Average and Median]
My beef is with people intuitively beginning to use an "average" or "median" algorithm for resolving differences between team members' estimates when they first see those cards coming up without a consensus.
The phenomenon of thinking ahead, trying to find a "solution" in parallel to receiving information is human nature. You can see it in, for example, a software developer starting to imagine what the system architecture will be already after reading the first two pages of the requirements specification.
This, I understand. I do it all the time.
But why average and why median? Why do we take these as some kind of a "safe bet", trusting that the truth must be close to the majority? Isn't it possible that the one who's in the minority knows more than the others?
Using an average or median algorithm for resolving differences (rather than trying to find a consensus through discussion) is like imagining the system architecture based on the first section of the spec. It's simply too soon! Just like the requirements specification always hides something you didn't quite take into consideration with your immediate vision of the architecture, the few minority votes behind those poker cards always include some very useful information that's worth unrevealing.
Really? Always? Isn't it the case that every now and then the minority vote was due to lack of knowledge about the domain, the code base, or an oversight of some kind?
Yes.
And that's why you should bring it up.
It's not just about getting the best possible estimate with the available knowledge. It's also about sharing that knowledge and improving those estimates in the future.
So bring up those arguments and try to get that consensus before resorting to the last word of average or median.