Release Planning: Risks, Dependencies, Learning, MMFS and Other

[This is a continuation of a series on Release Planning that starts here.]

Now we come to the point of (re)ordering the Product Backlog (PB).

Note: After calculating the R Factor, I like to order the PB by R.  Not that I would expect the Team to do the work in that order, but to get a view of what that would look like.  In this post, we are talking about ordering the work as we (currently) expect to do it.  Best guess.  (And we know that we will learn and improve the ordering later.)

You will recall that the Product Owner’s main goal is to maximize the Business Value from the Team to the Customer.  And deliver quickly.  The maximizing must happen in some time period (shorter or longer, as makes best business sense in your specific situation).  In theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceteris paribus (other things equal).

Of course other things are never exactly equal.

So, here is where the most uncommon thing comes into play.  Common sense.

There are many words we use for the other things to consider in ordering the Product Backlog.  Here are my names for them:  Risks, dependencies, learning, MMFS, and other factors. (MMFS stands for minimum marketable feature set. Aka MVP.)

I recommend anyone on the Team can propose to move a user story earlier or later based on any of these factors. But he or she must discuss the change with the Team and get a reasonable consensus.  If there is no consensus, then the Product Owner has 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 have a feature out before a competitor.  Or we have a weak understanding of 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.  There are also 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 clearly is to maximize business value, we sometimes must sacrifice the efficiency of the Team (to some degree).  But if technical dependencies will destroy or seriously diminish the efficiency of the Team, then we must deal with that.  There can be business dependencies as well.  It may make more sense to develop step 1 in a process before step 2.  At least sometimes.

Learning. In Agile we recognize the importance of learning, especially in the context of being knowledge workers doing knowledge creation. 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 change 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 a minimal set of features that must be put together before a customer can realize the value of the whole set.  Some of you know this idea as MVP (minimum viable product).  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 we think the MMFS is much larger than it really is.  In any case, low value features sometimes must be moved earlier, in order to add the ‘missing something’ to make the 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 gathering 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 (assuming no new user stories get identified, which is 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 happening.

In my 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.

I recommend that the product backlog be ordered by the R factor first.

Then I recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.

Then, anyone in the group can suggest re-ordering one PBI (user story) based on any of the ideas above.  Any move has to be explained to the whole group.  Anyone in the group may comment.  If there are disagreements that do not resolve quickly, the PO makes the final decision.

As more and more items are moved, at some point the PO starts to say ‘no’.  At some point, the argument to move the PBI is not as great as the argument in favor of the R factor being the key determinant (benefits to costs).

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 a few of the 50 user stories, where most do not move, does not take long.  Maybe in 10 minutes.  There can be some useful discussions, so it is ok if it takes longer than 10 minutes.  Do not let it last 1 hour.

More to come….

 

« « Enabling Specification || Self-organization of the Team » »