Question: How to order Stories in the PB

Question from a Class Attendee:

A question, about ranking user stories.
In the recent Scrum Master course, you indicated we should rank stories in the PB (Product Backlog) by Business Value and do them from the top down. In the Product Owner course back in 2011, you had us calculate R = BVP / SP to arrive at the cost / benefit value and then rank by R. This would have the effect of doing longer items ahead of shorter items that have somewhat less business value.
What do you recommend now? What are your current thoughts?

Reply:

I explain this at a decent length in my small book on Agile Release Planning.

I am still a fan of the R factor.  AKA ROI, bang for the buck, or cost benefit analysis. (Business Value Points divided by Story Points.)

And a fan of making stories small.  To me, all epics eventually must be broken down so that we can get 8+ items (stories) in a sprint.  So, if we have a velocity of 20 for a 2 week sprint, then items average about 2.5 story points.

As stories rise to the top and get broken down, we have to re-point (both BVP and SP).  Thus the R and the ordering will change.  For example a story with 100 BVPs and 20 SPs might break into two stories, one with 80 BVP and only 5 SP (R=16), and other with  40 BVPs and 16 SPs (R=2.5).  This is what Pareto might have predicted.  And note that when we break things down, we often discover that things are bigger (esp. effort) than we originally thought.

Not quite sure what your concern is, but I think that resolves it.

Note: When doing Priority Poker or Planning Poker, we of course use Wide-Band Delphi Estimation.  That is, we get the best experts we have to vote on BV and the best experts on effort.  Rarely, if ever, do those sets of people overlap.  The best experts on BV are typically the business stakeholders (as I define them) and the Product Owner.

The ultimate order of the work is never, in my experience,  ‘purely’ business value.  There are other things to consider (which we might also call business value, but to me it gets too complex to put it that way….).  Things like Risks, Dependencies, Learning, MMFS (minimum marketable feature set), and Other factors.

So, I like to use R factor. Rank by that. Then have the Team discuss changes to ordering, based on these other factors.

The most important thing is that the Team (and the business stakeholders) see the same elephant.

In the long term (or short term??) the PO needs to maximize the business value delivered to the customers.  I think.  As a contrasting example, the PO is not optimizing the ‘efficiency’ of the Team (that each hour is used ‘productivity’).

Does that help?

 

« « ROI for Scrum Training || ‘They still want us to deliver too much in too little time!’ » »