Release Planning: Business Value
[For those who have not been reading before, this is a continuation of a series that starts here.]
Now we move on to Business Value in Release Planning.
As Yogi Berra said: “You have to be very careful if you don’t know where you’re going, because you might not get there.”
If you are in the right mood, this can be very funny. Or just a chuckle. But this is our problem. How do we identify what the customer really really wants. The higher business value.
When we did the vision, we directly or indirectly probably talked about business value.
Now we want to talk about business value for each individual PBI (product backlog item) or user story.
Again, we want to have two actions within this: (a) identify the Business Drivers, and (b) do Priority Poker.
People: Again, to do this work, I want the whole team of pigs (PO, SM, implementers) and the BSHs (business stakeholders). Again, the BSHs are the best people we can get to attend Release Planning to represent the customers and the firm well.
It is my contention that the key thoughts and phrases we want to use about business value vary by the situation. The product, the customers, the people involved. It may be that the high-level basics of business value for all for-profit firms could be distilled into 5 phrases. But I find for useful discussions in specific products, it helps to ‘invent’ the 3-5 top drivers each time.
Business drivers may include making money, risk, customer satisfaction and lots of other things. Or, for a special product, not include things that were ‘obvious’ for a prior product.
So, the whole group gets together and discusses and agrees on the top 3-5 business drivers that apply to this set of work (the product) as represented in the existing Product Backlog (its PBIs). Sometimes this will lead to the identification of some new stories (or PBIs).
I expect most readers are familiar with Planning Poker, which is where we use the planning poker cards to vote as a team on the relative story points of [a new story] compared to the 1 SP on the [reference story].
Priority Poker is very similar to Planning Poker, except that it is about business value, not effort.
And, in fact, we assume there is no correlation between effort and value.
So, the similarities between Priority Poker and Planning Poker: use a team, vote, use Fibonacci cards, discuss assumptions, share knowledge and ideas, average the numbers after reaching some consensus. The number is comparative, relatively quick, somewhat imprecise for each individual card but fairly accurate over a set of cards, etc.
Some differences: a different team (the experts on business value), reference story is the TOP or biggest story (for business value) rather than the SMALLEST story (for effort), prefer the real Fibonacci sequence at the top end, done in the presence of the implementers.
The Business Value experts are typically the PO and the BSHs. And, if needed, maybe one member of the Team (one of the implementers) who has a lot of experience with customers. Or for some other reason, knows BV pretty well.
So, first the top experts (usually about 5 people, maybe 4-7) on business value huddle around the user stories (or PBIs) and determine which one has the most business value. This top one (the one chosen) is arbitrarily given a value of 100 BVPs (business value points).
OK, now we have the reference story for Business Value. Then the BV experts start to vote on relative BVPs (business value points) to each user story (or PBI).
Here are the rules:
* pick a story randomly (we do not want to prejudice the panel by already putting stories in BV order).
* discuss the story
* identify drivers of BV for that story (but not how much the driver is affected)
* ask each person to pick a Fibonacci card, but don’t reveal the vote to anyone
* once everyone has selected a card, 1-2-3, they all reveal their cards simultaneously
* the people with the two extreme cards (eg, a 2 is lowest and an 89 is highest) discuss why each was high or low
* the team re-votes until within 3 consecutive Fibonacci cards of each other
* then they average the numbers voted, to the nearest integer.
Example: The vote is 34, 55, 55, 89. The value for that story is 58.
Meaning: If the reference story is 100, and they vote 50, that means that they feel that the new story has 1/2 the business value of the reference story, considering all the different drivers of business value.
The others listening (the non-voters) may ask questions at the end of each card or story. The purpose for them being there is so they can pick up the tacit knowledge about business value, and which stories are more important (and why).
Final review: Once all the cards have been assigned BVP (business value points), the experts then gather around all the cards on the wall, and look for “the stupidest” numbers. Often in 50 cards, they will identify 3 or 4 that seem stupid now. Maybe this 30 seems a lot bigger than the other 30’s. Maybe that 70 seems too high now. The person identifying can ask the experts to re-vote. In general, we would expect them to re-vote on a few. After all, now that they have discussed them all, they are probably smarter now about business value than when they started.
Timing: Priority Poker takes some time, but is worth it. Understanding Business Value is very, well, valuable. Of course, one person in your group may talk too much. So, the facilitator must monitor that.
We find a time box of 1 to 1.5 hours is usually quite sufficient for 50 cards. But again, if the discussion is deemed valuable by most of the participants, it is ok if it goes a bit longer. But remind them to go pretty fast the first time. They can re-vote later, when they will be smarter. They do not have to be perfect today (and of course they were never going to be perfect).
We like them to think more and more that no two things have exactly the same business value. Yes, for example, we may have to do 5 steps in a business process, but steps 2 and 5 are exciting. The others are just chores that must happen. Steps 2 and 5, when we deliver them to the business and deliver them well, that’s when the big smiles come out. Or that’s when the big money is made.
Often new stories are identified. Or a few existing stories are deemed so big, that they must be sliced and diced into smaller stories. This is normal.
Sometimes an expert may feel he does not know how to vote on a specific story. He should take his best guess anyway. And learn from how the others vote.
Averaging: Apparently there are many who have been taught Planning Poker and told to force the team to consensus on one Fibonacci card. This is incorrect for Planning Poker. The research shows that averaging is more accurate and faster. And the same applies to Priority Poker.
Accuracy: Are all the cards perfectly accurately assigned BVP? No!
Have we learned a lot more about our different ideas about business value and shared that throughout the group? Yes!
Did the numbers help? Yes!
Can we change the BVPs later, once someone becomes ‘sure’ that one or more is wrong? Of course, by team vote.
Will we change some? I absolutely expect it. We want you to get smarter and smarter about business value, in multiple ways. This should in part be reflected into changes to the BV points.
Epics: If an epic is worth 100 BVP, does that mean that when it is broken into 5 stories, then each of the 5 is worth 20 BVP? No, we don’t assume that. In fact, along with Pareto, we assume that there are more vital parts of the 100 story, as well as less vital parts. In the simplest world, one of the smaller stories would be worth 80 BVP and the other 4 stories would total 20 BVP together (the 80-20 rules). But life is not always that simple, either.
There should be no requirement that the total BVPs on the children add up to the BVPs on the parent. The totals can differ, we are smarter now.
Results: One clear result is that we have a BVP number on every PBI (or user story). This is remarkable. And no one in the group thinks any of the numbers totally suck.
More importantly (IMHO), the whole team starts to share a bunch of ideas about how the BV is distributed amongst the features. Every feature is not equal. This is a great thing.
Typically new stories are identified. And typically the MMFS (minimum marketable feature set) is starting to emerge.
The main thing, to me, is that the whole group starts to share relatively specific tacit knowledge about the relative business value of each story. And key concepts about what ‘important’ means. Specific down to the user story, not hand waving at the vision level.
This work changes motivation. It changes the behavior of everyone. The business guys start to respect that the geeks understand them a little. And the geeks now understand better why business-side work is so hard.
The real value of all this work is getting closer. And will be revealed soon. Just a few more steps….