My First Experience with Business Value Poker

December 17, 2008 by Peter Stevens

Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?

Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.

Establish the value of a Value Point

The first thing we did is talk about the value of each feature. What did the top priority features mean to #1 in potential hardware sales? What did they mean in potential cost savings to #2? So we calibrated the scale: 100 Value Points (VP) = X dollars of hardware sales or Y dollars of operational savings.

Challenge the existing valuations

Next, we reviewed the existing valuations based on our new found reference values. Had the P-Ms valued the functions consistently? It turned out one feature had been substantially over-valued, the rest were pretty consistent with the actual business potential.

Estimate new features using the Cohn Scale

We used a modified Cohn Scale (more or less) to estimate the value of new features. Each estimate of value is assumed to be +/- 50% and we have Fibonacci progression on possible values. The idea that an estimate has high intrinsic uncertainty is even more compelling when discussing potential revenues or cost savings. Feature X might generate sales of 1000 additional units, but it might only be 500 and could be as much as 1500. Our actual numbers (which were based on the results of the previous point distributions) were pretty much what I suggested last week: 125, 250, 400, 700, 1250.

Where Prioritizing makes a difference

There was widespread agreement about the top two features. The problem is that they are both fairly big, one has an external dependency, and it is not clear whether either can implemented in the time frame of the next release. The next 5 or 6 features on the list all had similar appraisals (250 to 400 points) and were probably much smaller to implement. Which ones to do first?

To answer the questions, the P-M # 1 was asked to go back to his sales people and find out which of these features could have the most short term impact on sales. At the same time, we broke the high level stories down to estimatable user stories and will give that list to the implementation teams to estimate.

Once the product managers have this information, they can decide on how to prioritize the backlog for Sprint 1 with the goal of optimizing the return on investment.

Theory meets Practice

How did the method I suggest hold up in reality? We didn’t actually play poker. With two people who communicate well, it wasn't necessary. We did discuss the value of each story as described previously. Each P-M gave his assessment; these were added together and that became the consensus value. Given that two partners are investing in a project together, in retrospect, it seems obvious that the value of a story is (value to partner #1) + (value to partner #2).

The discussion process served to build a shared understanding of how we came to the numbers. Each P-M was able to accept the importance of a feature to the other, even if a certain feature had no value to his company.

Footnote: I discoved that a variation of Business Value Poker has already been proposed: Andrea Tomasini's Business Value Game. His discussion points for determining value are more closely based on quantitative ROI spreadsheets than the questions I proposed last week. He also suggested trying to arrive at a consensus for the value of each story, as in planning poker (and as I suggested last week).

My suggestion: the goal is consensus among the stakeholders. Use whichever questions work best for you and your project. And co-development is a cooperative game. Value = Value(1) + Value(2)+...+Value(n), where n is the number of partners.

Permalink