Release Planning: Business Value Points

September 27, 2011

One difference between what I recommend for Release Planning and what others recommend is Business Value Points (BVPs).

What do I mean?

First, is it useful to distinguish the Business Value (BV) of items in the Product Backlog? Yes, of course.

Why? Many ways to explain. One: Pareto says you can re-apply the Pareto rule (the 80-20 rule) at every level of the population. That means the rule of the “vital few” also applies to things “in the small”. We have to focus on the gold, the platinum, the diamonds, and ignore the silver and the copper, and of course ignore the dirt.

Also, it is very helpful to put numbers on the items. Numbers are clarifying. “Oh, 5 times more important? Well, in that case… Before I thought it was just a little bit more important.” It is useful to explain why something is important, but also useful to make it specific with a number.

A number does not magically make BV less complex. There are a myriad of things going on with BV. There is the MMFS (minimum marketable feature set), there are inter-relationships and dependencies. There is quality and beauty, etc, etc, etc.

Business value changes (and it is a prediction of the future). So, if we find things have changed enough (or we have learned enough), we can easily change the BV points (BVP) number.

Now, the most valuable thing about using BVP is not that we end up with a BVP number on each item. The most valuable thing is the discussion among the team and the business stakeholders.

OK, how do we do it?

First, discuss the 3-5 main drivers of BV. My hypothesis is that each project or product could define these drivers in a different way. So, get the business stakeholders and the PO together, discuss and agree on the main drivers. (I recommend the whole Scrum Team be there, and listen.)

Then, pick your 5 best experts on Business Value (really from 4 to 7 people); typically the PO and 4 business stakeholders who can represent BV well. Ideally people who will see different areas of BV (I am picturing 6 blind men and an elephant just now).

Then select the single item with the most Business Value. Make sure it is not what I call a super-epic (the epic that almost describes the whole project). It needs to be a reasonably small epic.

Call that “the reference story”. Give it a high number. I suggest 100 BVPs.

Get the Fibonacci cards out. Ideally real Fibonacci cards (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144).

Then take other User Story cards randomly, and compare them to the reference story (for BV).

The rules are just like Planning Poker, except that you are voting “how much smaller is this new story compared to the reference story?” If the reference story is 100, and the average for the new story is 50, that means it is 1/2 as important as the reference story.

I strongly recommend averaging once the “experts” get to within 3 consecutive Fibonacci cards of each other (a degree of consensus). Averaging leads to a better number, the research shows a more accurate number.

The implementer listens to the experts discussing and voting on BV. They learn. If they have questions, they ask. (Part of the purpose is to move the tacit knowledge of business value, of why we are doing this work, into their heads and hearts.) But the implementers cannot sidetrack the conversation.

After the team of experts has voted on all the user stories (PBIs), then the team looks over the whole set. Are any of them looking stupid now? If so, re-vote.

BVP can be re-estimated later, whenever we think we are smarter (or identify that we were stupid). They should happen fairly often — we are knowledge workers and always we are trying to get smarter. Understanding BV is really hard!

For now, we use our best guesses by our best guessers.

Side note: Why is Priority Poker not more common? I have no excuse. It is form of wide-band delphi estimation, and the agile community has been doing that broadly for decades now with story points. Wide-band delphi estimation goes back to the 1950s. I have no excuse. Exactly how and why it is so useful is not fully explained above. More later.