Prioritizing the Product Backlog

October 8, 2008 by Peter Stevens

Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.

Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?

I'm not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let's take a look at some widely used strategies for prioritizing the product backlog

• Minimum Marketable Feature Set - the first pass to narrow the list of stories
• Business Value First - Focus on High Value Functions
• Bang For the Buck - Go for easy wins
• Technical Risk First - Do the hard things first
• Defer Risk - Do the hard things later (or never)
• Vote - Ask your users

Get the Team Involved

If you haven't done so before, now is the time to talk to the development team .They should size the stories, possibly breaking them down into smaller stories that can be implemented in a single sprint, and discuss the technical risks of the project. If the story list is long, they should focus first on the minimum marketable feature set. Once you have the estimates from the team, you have the information you need to prioritize the backlog.

Value, Risk and Cost

We can classify stories based on the cost or risk of implementation versus the value of the story to the user, customer or company. "HH1" is some High-value, High cost (or High risk) Story, "HL2" is a High value, Low Risk story, etc.

Minimum Marketable Feature Set

A good place to start is to come up with a minimum marketable feature set. This constitutes enough Prerequisites and Exciter stories so that the product will be useful to and accepted by its users and give them a reason to buy it. This is not necessarily the feature set the product will initially ship with, as the priorities, market situation and other factors may change during the course of development. Your definition of "minimum" might even change. But it will help the team focus as they evaluate the story list.

Business Value First

The basic Scrum approach is to prioritize on the basis of "business value," on a scale of 1 to 100. This is merely a sort key. It is the product owner's job to assign business value.

This approach argues for focusing on the "HH" and "HL" stories.

How do you assign business value? You might start with the unique features of the system.
Given the dating site example from last week, the dynamic search categories and the rate-the-date functions would be highly prioritized. Once you have that, you can demonstrate it to stakeholders and potential users to get important feedback.

Next on the list are the prerequisite functions, e.g. registration, search, making contact, etc. When these functions are working you could do a beta release.

Given the problem of Congo Lomarate Corp, who wants to improve efficiency and reduce operating costs, you need to analyze and understand the processes find out where effort is being wasted. The stories which eliminate the most wasted effort would have the highest business value.

Bang for the Buck

Closely related to Business Value First, go for the low hanging fruit first, i.e. the stories which are easy to implement and which bring great value to the user or company. This means starting with the "HL" stories before attacking "HH" stories. So if 'Rate-a-Date' is easier to implement than dynamic categories, then the former would be top priority.

Technical Risk First

This approach, also advocated by Rational Unified Process, focuses on addressing the big challenges of the system first. This is a viable approach, which has been and continues to be applied successfully for large and embedded systems. The danger of this approach is twofold:

1. An excessively elaborate solution is produced for which there is no story or just a low value story which really needs the full solution
2. A simpler solution could have been produced later, when the problem is better understood or the scope is better defined.

Defer Risk

Similar to "Bang for the Buck:" start with HL stories, those which are clearly understood and for which the solutions are also clearly understood. Continue to investigate the HH stories or break them into simpler stories with lower risk.

I have found this to be an excellent method to keeps costs under control. Complicated stories have a way melting when you implement a little piece. Then add another little piece. The add another, and surprising quickly, the overall problem is solved.

Vote

This method works well for applications that already have a user base. Publish a list of potential features. Ask the users to vote on which ones they like best. Winners become top priority. (BTW - Doodle has a nifty tool for collecting votes).

The Real Work Begins

Once you have a prioritized product backlog, you have the prerequisites for the first Sprint Planning meeting. You can call your team together and start work on the actual project.

What works for you?

As I wrote in the beginning, there is no one right answer to this question. How do you prioritize the backlog? Why did you choose the approach you picked?

Permalink