Figuring out Business Value with Planning Poker

December 10, 2008 by Peter Stevens

In a perfect world, there is one product owner who knows the market, knows the application and can assign business value to each function on the backlog. But coming up with a dollar value for a feature can be difficult and in a joint venture the problem is compounded, because stakeholders with complementary interests may have a very different basis for valuing a function. There are two product owners, so the situation can be very delicate. How can the two parties agree on priorities for the next release?

Fundamentally, it is people who will agree, not the tools or the framework. So start by getting the people together to brainstorm on the vision and scope for the coming release.

Step 1: Get the vision down

What is the problem this release should solve? What should this release do and for whom? Before talking about functions, get agreement on the vision. If the near term vision is too contentious, try looking further down road and work back. Where should be product be in 6 months for all stakeholders to be happy? Then work back how to get there.

Step 2: Who are the users and what do they want?

This is classic User Centered Design approach. You need a list of user roles or “personae” and a list of features which you are considering for the release. Each feature should be described as a user story. At this point, the team should estimate the stories and the product owner should assign a business value, which is basis for prioritizing the implementation.

Step 3 Play Poker for Business Value

The problem arises when two or more stakeholders have diverging priorities for assigning value. This is where Business Value Poker can help.

Business Value Poker is similar to planning poker, except

• Participants discuss the value of the feature and not its complexity.
• Valuations are on a Fibonacci-like scale: 0 1 2 3 5 8 13 20 30 50 80 130... You can also expand this scale upward if necessary, but two orders of magnitude should be enough.
• The Reference “Value Point” is based on a highly valued story, not the smallest story.

Each stakeholder gets one player. You need at least two people to play. Maybe the Scrum Master is a player or maybe just a moderator. You might also include other domain experts, e.g. people from sales, support, production, etc.

Before you start, you will need to establish your teams “Value Point Standard” - What is a value point? Pick a top priority story and give it the value 80. Then calibrate that value by discussing what makes it valuable:

• What does the feature mean to its user?
• What does the user mean to the product? Potential purchaser, marketing partner, simple user, influential user, investor…
• What does the feature mean to the company or companies developing it?
• How would you rate feature on the Kano scale (Pre-Requisite, Positioner, Exciter or Deterrent)?
• What is the consequence of not implementing the feature?
• What is the consequence of delaying implementation of the feature?

This builds a common understanding of the value of that feature. This will help you agree on a value for other features.

Next, go through all of the remaining stories, discuss each one for maximum 3 minutes according to the same criteria, then vote as in planning poker.

Handling Disagreement

As with Planning Poker, if there is disagreement after the vote, let the high and low voters present their reasoning and vote again. You might want to repeat this process once, but if there is still disagreement (especially if there are only two voting participants), I would record both votes and move on. An average will put the feature somewhere in the middle, which is probably something neither party wants, and which might encourage compromise.

If there is serious disagreement on the value of a story, there are a couple of possibilities:

1. Postpone handling that story until after all the other stories have been dealt with. Don’t get hung up on one or two stories and forget to value all the others.
2. Identify the minimum feature set needed to meets the business need. If a set features can be identified which is small enough to implement in a single release, then the priorities of both product owners can be reflected in that single release.
3. Increase the number of participants. Just as the wisdom of crowds works in planning poker or forecasting elections, more people come to a better conclusion than few people. Customers, customer proxies, supporters, trainers or domain specialists may all be able to provide additional voices.
4. Include high level management. Sometimes higher level management can take a more strategic view of the situation.

What if you still can’t agree? Well you could try dueling. At this point it is probably better to delay the problem. Let the team estimate the stories. Have them do some analysis. Look for ways to implement the desired features with less effort. Sometimes problems which seem intractable become solvable with study and more understanding.

Prioritizing

So now you have list prioritized by business value? Is this the same as the final priory for the product backlog? Not necessarily. The team will estimate the cost of implementing the features on the product backlog. Prioritizing will probably depend both on business value and the cost to implement. And of course, horse trading among the partners in a joint venture is always a genuine alternative to get a happy settlement.

Permalink