Now we come to the point of (re)ordering the Product Backlog.
(This is a continuation of a series on Release Planning that starts here.)
You will recall that the Product Owner's main goal is to maximize the Business Value from the Team. In some time period (shorter or longer, as makes best business sense in your specific situation). So, in theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceretis paribus (other things equal).
But of course other things are never exactly equal.
So, here is where the most uncommon thing comes into play. Common sense.
And we re-order the work based on these factors: Risks, dependencies, learning, MMFS, and other factors.
We recommend that anyone in the Team can propose to move a user story earlier or later based on these factors. But he or she must discuss the change with the Team and get reasonable consensus. If there is no consensus, then the Product Owner gets the final decision.
So, let's discuss each factor in turn.
Risks. There are potentially many types of risk. Business risk is often a big one. For example, we need to get a feature out before a competitor. Or we have a weak understanding of the specific detailed features needed in area X. Technology risk is another common factor. We are about to use new technology, and we are not sure how it will work. And there are other types of risk. In Scrum, we tend to want to attack risk early, by doing one or more stories in that area, to see if the risk is just a worry, or a real roadblock.
Dependencies. Again, these can be of several types. In the past, we often organized the work mainly by technical dependencies. Since the job now is to maximize business value, we sometimes must sacrifice efficiency of the Team. But if technical dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok, seriously diminish the efficiency...). And there can be business dependencies as well. It makes more sense to develop step 1 in a process before step 2. At least sometimes.
Learning. In Agile we recognize the importance of learning. We need to learn what the customers really want. We need to learn some technical things to become more effective. These can be good reasons to chnage the order of the work.
MMFS. Minimum market feature set. This phrase is from Software By Numbers by Mark Denne and Jane Cleland-Huang. The idea is that there is some minimal set of features that must be put together before a customer can realize the value of the whole set. Sometimes this minimum is quite small, quite small indeed. In other circumstances it is much larger. In general, too many of us (producers and customers) have been brainwashed into believing the 100%-100% rule, so that we think the MMFS is much larger than it really is. In any case, low value features sometimes must be moved up, in order to add the 'missing something' to make the next release truly 'usable'.
Other. This is a catch-all for all the other reasons we have to change the order of the user stories. My favorite example is this: A committee is going to me in 3 weeks to decide on the funding for our project. George is on the committee. In our opinion as PO and in the opinion of everyone else, George is much too excited about user story 87, which currently would not be built until the third release, and that is assuming no new user stories get identified, which is very very unlikely. But, George is on the committee. And user story 87 is only 5 story points (our velocity is 25). So, we ask the Team to go ahead and get the story done in the next Sprint so that George helps assure that the project gets further funding. Not rational, not 'the right thing to do', but sometimes you have to deal with real people and irrational things have to happen.
In our experience, Risks and Learning should be used more often to re-order the product backlog. And Dependencies less often. But in any case, using the R factor solely is almost never the right answer.
How to do this
We recommend that the product backlog already be ordered by the R factor. (The R factor was discussed in the previous post on Release Planning.)
We recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.
Then, anyone in the group can start to suggest re-ordering the product backlog based on any of the ideas above. Any move has to be explained to the whole group. If there are disagreements, the PO makes the final decision.
Again, let me emphasize that sharing knowledge with the whole team is at least as important as any other outcome we are trying to achieve. So, doing this without the Team is not recommended.
Normally this does not take very long. Again, 6 months of work for one team is typically expressed as about 50 user stories. So, re-ordering 50 user stories, where most do not move, does not take long.
More to come....
(This is a continuation of a series on Release Planning that starts here.)
You will recall that the Product Owner's main goal is to maximize the Business Value from the Team. In some time period (shorter or longer, as makes best business sense in your specific situation). So, in theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceretis paribus (other things equal).
But of course other things are never exactly equal.
So, here is where the most uncommon thing comes into play. Common sense.
And we re-order the work based on these factors: Risks, dependencies, learning, MMFS, and other factors.
We recommend that anyone in the Team can propose to move a user story earlier or later based on these factors. But he or she must discuss the change with the Team and get reasonable consensus. If there is no consensus, then the Product Owner gets the final decision.
So, let's discuss each factor in turn.
Risks. There are potentially many types of risk. Business risk is often a big one. For example, we need to get a feature out before a competitor. Or we have a weak understanding of the specific detailed features needed in area X. Technology risk is another common factor. We are about to use new technology, and we are not sure how it will work. And there are other types of risk. In Scrum, we tend to want to attack risk early, by doing one or more stories in that area, to see if the risk is just a worry, or a real roadblock.
Dependencies. Again, these can be of several types. In the past, we often organized the work mainly by technical dependencies. Since the job now is to maximize business value, we sometimes must sacrifice efficiency of the Team. But if technical dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok, seriously diminish the efficiency...). And there can be business dependencies as well. It makes more sense to develop step 1 in a process before step 2. At least sometimes.
Learning. In Agile we recognize the importance of learning. We need to learn what the customers really want. We need to learn some technical things to become more effective. These can be good reasons to chnage the order of the work.
MMFS. Minimum market feature set. This phrase is from Software By Numbers by Mark Denne and Jane Cleland-Huang. The idea is that there is some minimal set of features that must be put together before a customer can realize the value of the whole set. Sometimes this minimum is quite small, quite small indeed. In other circumstances it is much larger. In general, too many of us (producers and customers) have been brainwashed into believing the 100%-100% rule, so that we think the MMFS is much larger than it really is. In any case, low value features sometimes must be moved up, in order to add the 'missing something' to make the next release truly 'usable'.
Other. This is a catch-all for all the other reasons we have to change the order of the user stories. My favorite example is this: A committee is going to me in 3 weeks to decide on the funding for our project. George is on the committee. In our opinion as PO and in the opinion of everyone else, George is much too excited about user story 87, which currently would not be built until the third release, and that is assuming no new user stories get identified, which is very very unlikely. But, George is on the committee. And user story 87 is only 5 story points (our velocity is 25). So, we ask the Team to go ahead and get the story done in the next Sprint so that George helps assure that the project gets further funding. Not rational, not 'the right thing to do', but sometimes you have to deal with real people and irrational things have to happen.
In our experience, Risks and Learning should be used more often to re-order the product backlog. And Dependencies less often. But in any case, using the R factor solely is almost never the right answer.
How to do this
We recommend that the product backlog already be ordered by the R factor. (The R factor was discussed in the previous post on Release Planning.)
We recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.
Then, anyone in the group can start to suggest re-ordering the product backlog based on any of the ideas above. Any move has to be explained to the whole group. If there are disagreements, the PO makes the final decision.
Again, let me emphasize that sharing knowledge with the whole team is at least as important as any other outcome we are trying to achieve. So, doing this without the Team is not recommended.
Normally this does not take very long. Again, 6 months of work for one team is typically expressed as about 50 user stories. So, re-ordering 50 user stories, where most do not move, does not take long.
More to come....
No comments:
Post a Comment