Using Planning PokerTo Increase Collaboration and Gain Consensus

One of the interesting aspects of Kanban is its attitude towards estimation. There are some in the community of kanban practitioners believe that estimation is an unnecessary activity.

I asked for clarification during a recent conversation with David J. Anderson, and his opinion was that estimating was a good thing to do, provided the following 2 points:

1. estimates could be created quickly and cheaply
2. estimates produced were of high-quality

Recently, we have been supplementing what started off as a largely "pure" Kanban project with more and more agile style practices. One of these which is getting great traction is planning poker, a collaborative estimation game.

Our rationale for doing planning poker actually has very little to do with getting good estimates. My colleague, Alexis Hui and I were actually a lot more concerned with getting more team buy-in towards commitments made, collaboration on what the solution should look like before delivery started, and better consensus between architects and developers.

What is interesting is that we limited the estimation range to be between 1 and 13, if something could not fall within that range we needed to break it up or do more research before completing the estimate. Prior to this meeting, I had already provided estimates to the executive sponsor where every story simply equaled 8 days each. As each story was estimated during time poker, the numbers typically were either 5 or 8, and only occasionally did they fall outside that range.

The total estimated number created by the planning poker sessions were almost identical to the ones were all stories equaled 8. So was the estimation session a waste of time? Absolutely not, the one thing that I've noticed about collaborative estimating games, is that they generate a lot of valuable information, often a lot more valuable information than generic modeling sessions. There is something about thinking about how long something takes that causes the mind to shift to a very practical and pragmatic solution. When a cross functional team takes part in this exercise the entire team gets quick alignment around not only what should be done, but how it should be done.

So I'm going to add a third point for when to estimate as an additive to the above 2:

3. When you want to quickly generate information and gain agreement on how to proceed

below are some pictures from the planning poker session: