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:

Using Cost of Delay Functions to Prioritize Product Delivery

In many "agile" projects I’ve been a part of my strategy was to break off specific functions / use case / stories / whatever and delivery them mostly whole one piece at a time. IE in iteration 1 go deliver order entry functionality, in iteration 2 go deliver product fulfillment.

While this approach help keep delivery efficient by breaking up work into smaller units, it does nothing to help business agility. When delivery a product an agile approach is to look at the product from a truly incremental perspective. What is the minimum that one can deliver right now that would meet some basic objectives of the product, what are the next set that would make the product a little better, and so on until I get that ideal product, one releasable piece at a time.

Using this approach means it’s not enough for teams to develop code each iterations that is production worthy. Rather the entire organization needs to think about releasing products to the market in increments.

For this to work the business needs to train them selves to stop asking if they can get the world a year from now, but if they can get a small piece of the world next week.

A colleague of mine, Alexis Hui came up with a very innovative way to manage this approach on a project that we were running. The approach was to extend our Kanban board with a capability and theme map, illustrated below.


The whiteboard was divided into sections based on major capabilities that the product had to meet. Capabilities were further broken up into major project themes that has numerous theme "attributes". Each attribute could be thought up as a feature that could be revisited numerous times over the lifecyle of the project. Each time the attribute required new work a story would be tagged with the theme and attribute.

As an example the provisioning handset capability might have a theme for voice mail that had an attribute for activation and one for de-activation. An initial story would describe the work necessary to provision voice mail on a cell phone with a very simple set of features, a later story would describe fancier features like visual voice mail.

Each theme/attribute set would act as a persistent queue, where stories could be placed.

We then used a concept known as a Cost of Delay Function to prioritize stories. Think of a Cost Of Delay Function as a simple way to profile the impact of not doing a story on the business, or in this case the project. COD, also known as Opportunity Cost, is often graphed as a line showing the relationship between impact vs time, the steeper the angle of the line, the worse the impact is over time. COD can represent financial, political, moral, or other impact that could adversely impact the organization.

While it can be very hard for an organization to know the exact impact over time for not doing a particular work item, one is frequently able to allocate the COD into a broad category or profile. When using COD I recommend using color, or annotations to tag work on a Kanban board to identify it’s COD profile.


Because our project was all about launching a new product, we decided to base our COD profiles loosely on market risk.

Orange tickets represented work items that were necessary to launch the most basic version of the product, the COD on this is represented as a straight vertical line. If we did not deliver these by the target date of the first release then the project would be deemed a failure. These were necessary to enter the market.

Beige tickets represented a second pass at the orange tickets, taking mostly manual bare boned functions and automating them, adding better error handling, and other work to make sure that a fully operational product would support more than a limited pilot. This COD was illustrated as an incremental line starting right way, we were losing money everyday these weren’t implemented, and things would get worse the longer they weren’t delivered. These tickets were necessary to support market growth.

Green tickets represented high end features like customer self care, power tools, customizations features, and market grabbing functions such as keeping a phone number when transferring to the new plan. COD here was illustrated much like the beige tickets, but with a delay before incurring losses, and a more pronounced curve on the line, we didn’t need these features right away, but they were quite valuable later on. These tickets were necessary to steal market share from competitors.

Blue tickets represented longer term investments. Completing a blue ticket did not result in a noticeable business impact. Rather work quality would improve. Architecture work, educating the team on agile practices, refactoring, technical docs, were all profiled as blue tickets. These tickets had a straight horizontal line with a slight upward slope to it, immediate value was not obvious to the business, but not doing them would result in downstream pain. These tickets were necessary to ensure that the IT team could continue to support other market needs at a reasonable pace and price.

The above diagrams shows stories colored by COD. One can easily see which capabilities are more critical to earlier stages of development, and which ones should be done later. It should be noted that prioritization is not as simple as choosing one color, than choosing another, than another. Different business and different projects will choose a different allocation of COD profile tickets depending upon where they are in the product life cycle.

COD allocations are also dependent on the nature of the business they are in, for example start ups will likely face more extinction level events than blue chips, and have more "warm" colored tickets in flight to respond to these events.

It was typical using this approach to revisit an attribute several times. The first story for an attribute may be a blue ticket involving a spike, POC, or actual design. Subsequent stories for the attribute could involve one more orange and beige tickets, depending on the desire for a mostly manual solution or full automation of a component out of the gate. Later stories would often be a series of blue and green tickets necessary to POC new technologies and implement new functionality necessary to support some high end feature.

The one common theme here is that the simple use of color can be used to convey an awful lot of information with deep meaning to the business, helping delivery support real agility.