One thing different about what I recommend for Release Planning and what others recommend is Business Value points.
What do we mean?
First, is it useful to distinguish the Business Value (BV) of items in the Product Backlog? YES!
Why? Well, Pareto says that 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, the copper, 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 myriad things going on, and changing with BV. There is the MMFS (minimum marketable feature set), there are inter-relationships. There is quality and beauty, etc, etc, etc. If we find things have changed 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 numbers on each item. The most valuable thing is the discussion amongst the team and the business stakeholders.
OK, how do we do it?
First, discuss the 2-5 main drivers of BV. My hypothesis is that each project or product could talk about these drivers in a different way. So, get the business stakeholders and the full Scrum team together, and discuss and agree on the main drivers.
Then, pick your 5 best experts on Business Value (really from 4 to 7). Ideally people who will see different parts of BV (I am picturing 6 blind men and an elephant just now). Typically these people are the Product Owner, and 4 business stakeholders (including maybe a real user or end user!).
Then pick 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 highest number". Say, a 130 on my scale above. Or if you are using regular planning poker cards, a 90 or 100.
Then get the Fibonacci cards out. Ideally real Fibonacci cards (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144).
Then take User Story cards randomly, and compare them. Then 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 90, and the average for the new story is 30, that means it is 1/3 as important as the reference story.
We 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 resulting number.
The implementors listen 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 implementors 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. Understanding BV is really hard!
What do we mean?
First, is it useful to distinguish the Business Value (BV) of items in the Product Backlog? YES!
Why? Well, Pareto says that 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, the copper, 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 myriad things going on, and changing with BV. There is the MMFS (minimum marketable feature set), there are inter-relationships. There is quality and beauty, etc, etc, etc. If we find things have changed 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 numbers on each item. The most valuable thing is the discussion amongst the team and the business stakeholders.
OK, how do we do it?
First, discuss the 2-5 main drivers of BV. My hypothesis is that each project or product could talk about these drivers in a different way. So, get the business stakeholders and the full Scrum team together, and discuss and agree on the main drivers.
Then, pick your 5 best experts on Business Value (really from 4 to 7). Ideally people who will see different parts of BV (I am picturing 6 blind men and an elephant just now). Typically these people are the Product Owner, and 4 business stakeholders (including maybe a real user or end user!).
Then pick 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 highest number". Say, a 130 on my scale above. Or if you are using regular planning poker cards, a 90 or 100.
Then get the Fibonacci cards out. Ideally real Fibonacci cards (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144).
Then take User Story cards randomly, and compare them. Then 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 90, and the average for the new story is 30, that means it is 1/3 as important as the reference story.
We 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 resulting number.
The implementors listen 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 implementors 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. Understanding BV is really hard!
No comments:
Post a Comment