Skip to content

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.
Table Classifying Stories by Value and Cost

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?

About the Author: Peter is an independent Scrum Trainer and Coach. His mission is to help you realize complex projects. He provides coaching, training and project management to help you get started with Scrum, save projects in crisis and make your IT operations leaner and more effective.

Originally from the US, Peter now lives in Zurich. He studied Computer Science at Colgate University, started his career at Microsoft, and is now a Certified Scrum Master (Practitioner). He speaks English, German, French and Italian. An Instrument rated private pilot, his current hobbies are sign language and Sudoku.

Comments

Vote

October 8, 2008 by pbielicki, 1 year 23 weeks ago
Comment id: 1894

JIRA Issue Tracker has a great voting capabilities (well, it's quite simple) and works fine at least in the open-source world. But you have to use JIRA to have it.

I think other issue tracking systems also have similar capabilities. So, if you can store user stories there you can vote them too.

Cheers!

Poker Prioritization

October 8, 2008 by Kevin E. Schlabach (not verified), 1 year 23 weeks ago
Comment id: 1895

We had a product where the backlog clearly could not be covered in the first release. Our customers were hospitals that didn't budge on "their needs".

We pulled our top 10 highest paying potential customers into one site and gave each one a bag of poker chips. They were asked to "pay" using their chips for certain features. They were told they could plop all their chips on one feature, or spread evenly across many.

As they saw each other "pay", they shifted their chips around. They didn't "waste" money where their peers didn't care, and they spread money to provide emphasis where peers needed help.

We walked away with a greatly pared down set of features that everyone was invested in (pun intended) and they felt like they were part of the process.

That's what we ended up building.

Very Cool Idea!

October 8, 2008 by peterstev, 1 year 23 weeks ago
Comment id: 1896

I like it. :-)

I have a little different approach

January 6, 2009 by Patrick Merg (not verified), 1 year 10 weeks ago
Comment id: 2151

Hi
This is a really good article, thank you for posting it. We use MoSCoW ratings to do the initial product backlog prioritization, for us it helps us quickly understand what is most critical for the product owner.

http://patmerg.blogspot.com/2009/01/user-story-prioritization-part-1.html

Pat

Moscow is not a bad place to start

January 6, 2009 by peterstev, 1 year 10 weeks ago
Comment id: 2152

Hi Pat

One of my first projects, we had a very long list of wishes which we need to have converted into a prioritized backlog. The customer/new product owner rated everything on a 1 / 2 / 3 scale. He noticed himself that there were so many prio-1's that he introduced a priority 0 to distinguish what was really important to him. Must on the Moscow scale. And like in your case, those are the stories we actually implemented.

I don't like Moscow for prioritizing stories for the sprint planning. It creates pressure from the P-O to favor volume over quality (cheat on the definition of done to get more features done). A simple numeric scale is emotionally neutral.

A variation for the team to express its commitment might be called "WilCoW" - will be in, could be in, won't be in. I have worked with many teams which like to commit at two levels, leaving some stories which they can implement if things go well, but for which they owe no explanation if things only go as planned.

Cheers,
Peter

User Story Mapping is also a very useful option

March 12, 2009 by markb (not verified), 1 year 1 week ago
Comment id: 2348

I recently used User Story Mapping in a specific situation which helped with the prioritisation. The practice has helped the customer and technical teams understand which stories are "less optional" and those which are "more optional". The ensuing discussions about the user stories looked at a range of priorities including business value and technical risk. MInd you, we needed a large wall to perform the story mapping! ;-)

As a side issue the process also addressed your blog topic of the (ie. As a etc...) as only the Activities were formally stated in this way. All the subsequent user stories were structured as suited the individual user story. In fact most came out as " " but others had their own individual style.

User Story Mapping is also a very useful option

March 12, 2009 by markb (not verified), 1 year 1 week ago
Comment id: 2349

Apologies for the re-post but I stuffed up the original post. That'll teach me to preview first.

I recently used User Story Mapping in a specific situation which helped with the prioritisation. The practice has helped the customer and technical teams understand which stories are "less optional" and those which are "more optional". The ensuing discussions about the user stories looked at a range of priorities including business value and technical risk. MInd you, we needed a large wall to perform the story mapping! ;-)

As a side issue the process also addressed your blog topic of the standard user story (ie. As a etc...) as only the Activities were formally stated in this way. All the subsequent user stories were structured as suited the individual user story. In fact most came out as "action verb" "object" but others had their own individual style.

User Story Mapping Article: http://www.agileproductdesign.com/blog/the_new_backlog.html
Story Point Format Blog: http://agilesoftwaredevelopment.com/blog/artem/why-i-dont-use-standard-u...

RE: User Story Mapping

March 12, 2009 by peterstev, 1 year 1 week ago
Comment id: 2353

Thanks for the tip on user story maps. The Big Visible Task Board is such a helpful tool for making project status visible. A Big Visible Spec Board is an intriguing continuation of this concept. Gotta look at that one in more detail... :-)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters (without spaces) shown in the image.

Best of AgileSoftwareDevelopment.com