Wide-Band Delphi Estimation for Business Value – 3
This is the third in a series of three. See Part 1 and Part 2.
____________________________
How can we use the BV points?
We could organize the Product Backlog strictly by BVPs, at least initially. In fact, I recommended this, to see patterns or to make any mistakes obvious. Put the story cards in rows of roughly equal business value. Ask: Do do any of these cards seem to be in the wrong place?
But, I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first. This is much too simplistic.
The key thing we are missing is cost. For centuries now, man has talked about the trade-off between costs and benefits, and in business we have the concept of return on investment. You invest $1,000 (the cost) and get $2,000 back (the benefit).
Can we use that concept here? Yes!
For each story, we can calculate an R factor by dividing the BVPs by the SPs. This gives us a rough ROI for each story. We could call it cost-benefit analysis (CBA), or Bang for the Buck.
This is useful.
By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R factor could help us maximize the Business Value per release, other things equal.
Again, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things. Here some things I also consider: Risks, Dependencies, Learning, MMFS/MVP, and other factors. (MMFS = Minimum Marketable Feature Set, and MVP = Minimum Viable Product. These arguably are two acronyms for the same thing. Somewhat different metaphors.)
What is the value of a BV Point?
Sooner or later someone will ask: What is a BV Point worth?
At first, it is relative, strictly relative. That is Story X is 50 BVPs, which means experts guessed it has half the value of the reference story (which has 100 BVPs).
But let’s imagine a very simple situation and see what it shows us.
Imagine a Product Backlog. Say 50 stories.
Imagine it has a total of 2,000 BVPs across all of the stories.
Imagine that we know that the total Product Backlog will generate an NVP of $4 million. (NVP = Net present value over the life of the product.)
In that case, we can calculate that each BVP on average is worth $2,000.
You can’t cash in your story cards at the bank for money (based on the BVPs on each one). You must release and there are MVP or MMFS issues as well, but one can feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality. Well, if the customer still wants it when we deliver, and if we had good BV estimators, and IF…
Objectivity and Visibility
In my opinion, whatever Business Value is, it is ultimately in the mind of the customers in the future.
So, as business people trying to solve a business problem (help people and not go bankrupt), this may seem altogether too subjective.
The BVPs start to make it a more tangible thing, and this helps. Think: more visible. At least our guess is more visible.
Whatever number we decide on is then no longer a ‘feeling’ inside us (or one of us, such as the PO), but rather a number ‘out there’ on the story card.
This helps. It helps in many ways, but let’s give one example.
In former days, we would ask two experts for Story X: Is it high, medium or low? And of course they would both typically say high. Now, we ask the two experts to vote with cards. One says 21 and the other 89. We and they can quickly see that one “high” is not the same as the other “high,” and they can start to have the conversation about how high is high. We can laugh, but actually this is a useful conversation.
In fact, one of the most valuable things about the numbers is that it makes the conversations better.
Tacit Knowledge
I just gave the example of the more useful conversation that arises.
When they vote, and they disagree significantly (wider than three Fibonacci cards), we want the two extremes to talk. Others may talk as well.
In this conversation, they will share tacit knowledge.
What do they talk about?
Well, we think it is best to think of this as sharing the tacit knowledge. Here’s an article on tacit knowledge that also mentions Takeuchi and Nonaka, the godfathers of Scrum: https://en.wikipedia.org/wiki/Tacit_knowledge
The experts might also share some explicit knowledge. This happens less, and it is (somewhat) less problematic. That is, one can easily imagine giving some explicit knowledge to another person by giving them some paper. Very easy. (Well, not always. One problem: Will the person read it? And understand it?)
One definition of tacit knowledge is “all that stuff we know, but we often don’t even know we know it, and it has not been made explicit yet.” Obviously, we mean knowledge that is relevant and even useful in a given domain, or to accomplish a given set of work. Explicit knowledge is knowledge that has been written down or put in a formula.
Do you want a team to share their tacit knowledge? Of course! In all the relevant domains.
Is it easy to get them to do so? NO! It is normally extremely hard. In part because they don’t know what they know, and in part because each person doesn’t know what the other people (eg, in the team) are missing.
Priority Poker forces them, in a fun way, to share the tacit knowledge.
Priority Poker is also a game. That means that every person is active and wants to “win”. And so, almost as well as teenagers, these adults suck up and actually remember the information conveyed to them. If you work with adults much, you will recognize this as a miracle! They absorb the knowledge!
In my opinion, this is the most valuable thing about the whole exercise. Not that other things would not justify it, but the sharing of tacit knowledge is the single most useful thing, in my opinion.
Helping the Product Owner
Priority Poker makes the PO job easier, and it is a very hard job, so any help is welcome.
In what way?
Without Priority Poker, the PO had to make tough choices in ordering the Product Backlog. And the Product Owner needs to get other people aligned with those choices. Otherwise, the Sprint Review meetings will be rough: “Why did the team do that story? I told you I like this story more!”
Let’s assume, in former days, they talked to all of the Business Stakeholders individually, and they disagreed, of course, on the values of different stories.
So, the PO had to use up his political capital in just saying and “getting agreement on”: This story is #1, this one #2, etc., etc.
This was ‘risky’ and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two Business Stakeholders.
Now, with Priority Poker, it’s a game and all the Business Stakeholder “educate” each other. (Again I say, bring the popcorn. This is fun to watch.) “No, you’re wrong. Let me tell you why…” Definitely education is taking place. And mostly the Business Stakeholders are educating each other.
Still sometimes, in relatively rare cases, all four of the Business Stakeholders are being stupid at the same time, and the PO’s number will make only a small difference in the average. Let us assume the PO’s number is right. Only then does the PO have to use political capital to ‘move’ the story to a more correct BV number or more correct ordering. (Ok, mainly then…)
This reduction in effort frees the PO to focus his work and energy in other areas.
Overall Benefits
I want to reiterate the key overall benefits I mentioned earlier.
- They all see the same elephant (better)
- They all are more motivated
- They all have shared the tacit knowledge
If Priority Poker is done with the implementers, these benefits accrue to the whole team. Remember that motivation is not just a ‘feel good’ thing; higher motivation directly leads to higher productivity from the team.
I hope you try Priority Poker soon, and tell us how it went. Please tell us how much it helped you.
If you need an agile coach or consultant for this, to get you all started, please contact me. But soon, you can do it yourselves.
« « What is Scrum? || Scrum makes work a Game. » »