Prioritization Techniques for Your Backlog

Do you ever look at your product backlog and feel overwhelmed?

Do you feel that no matter how many features, user stories, and fixes you deliver, more keep piling up?

Are you juggling a mountain of requests from users who all want to know when their favorites will be completed? Can you justify why your priorities are what they are?

If these scenarios sound familiar, have you sat down lately to prioritize your product backlog? 

In this article, we will look at:

• What are backlog prioritization techniques?
• Why is backlog prioritization important?
• And seven backlog prioritization techniques, including:
  • Stack ranking
  • RICE prioritization
  • Kano model
  • MoSCoW method
  • Value/Effort Score
  • Cost of delay
  • Weighted Shortest Job First (WSJF)

What are backlog prioritization techniques? 

A backlog is a prioritized list of what your development team will work on to improve your product. It is maintained by the product manager or product owner and can include new features, improvements to existing features, and bug fixes.

To ensure product success, the product manager or product owner must determine the order in which features will be developed. Backlogs don’t work like a line at the grocery store where the first person in line is the first person the cashier rings out. Instead, as you know, backlog prioritization techniques can be used to determine which features on your list represent the highest value.

It can seem counterintuitive that some features may sit on the list for a while – aren’t you risking having an angry mob of users upset that somebody’s feature request was completed sooner than theirs? We certainly wouldn’t be happy if someone cut us in line at the store. If you use an appropriate technique to prioritize your backlog, you’ll be able to figure out which features make the most sense to produce the most benefit sooner. You can also give a good reason why someone else’s requested feature “cut” in line.

What are the benefits of using backlog prioritization techniques? 

Backlog prioritization gives product management the ability to focus on what will create the most value for users in a product. Or the most value for your company. Or both.

Prioritizing the product backlog helps you determine the order in which backlog items should be developed. With limited resources, of course, you can’t deliver “everything, everywhere, all at once”. Prioritization allows you to deploy your resources most effectively.

Prioritization techniques give you a productive way to make strategic decisions about what to do and when. Using them gives the product management team and the development team a common view of the work ahead. 

A prioritized backlog also provides sequence. If you’re using Agile development techniques like Scrum, it provides the basis for sprint planning, or for Kanban pulls. If a team member has extra time and needs to pull the next feature, they can. (In some more disciplined environments, team members aren’t given that degree of autonomy 😬).

Of course, applying backlog prioritization techniques gives you a consistent way to not only prioritize, but also to rationalize and communicate to others not only the priority you’ve chosen, but also how you arrived at them, and why that matters. 

Justification helps when there are questions about why a certain feature has been on the backlog for a while. When angry users (or the Chief Product Officer) asks why the feature they requested last month isn’t out yet, you can explain where it falls in the backlog, and why.

Example backlog prioritization techniques

There are lots of choices when it comes to prioritization techniques. Each has value in certain situations. In this article, we briefly describe seven of them and suggest where they might best be used. Let’s take a look at some backlog prioritization techniques.

1) Stack ranking 

Stack ranking involves comparing (pairwise) each feature or other work item to each of the other backlog items and determining which of the two is more important. After each feature or work item has been compared to each other feature or work item, you end up with a prioritized list.

A benefit of stack ranking is that since you’ve compared each feature to each other feature, the priority, or ranking, is clear when finished. You can use it if you have a smaller list of features, so the ranking can be done fairly quickly. 

And no complex formulas or categories are involved (so is it pretty subjective, then?). It’s ideal for determining which user needs to address, or even for users or customers to rank potential product improvements.   

When you have many features; this method can be cumbersome and time-consuming. Having to compare one hundred features in a pairwise manner will likely make your eyes glaze over. 

That’s more than 4,900 pairs to compare! (You’d have to provide lunch and dinner for that meeting to get people to sit through it, not to mention a considerable number of bathroom breaks).

2) RICE prioritization 

RICE prioritization involves looking at Reach, Impact, Confidence, and Effort.

Reach looks at how many users are affected in a specific period. You need to define what “reach” means and the length of the time.

Impact means how much the feature will help customers. Use a numeric value to assign the impact. Intercom, the inventor of RICE, uses 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Again, you need to define what “impact” means.

Confidence is how accurate you think your estimate is. Using Intercom’s method as an example, 100% is high confidence, 80% is medium confidence, and 50% is low confidence. Anything below that is, well … about as sure as the chance of hogs taking flight.

Effort is how much work it will take to complete the feature or whatever you’re prioritizing. It’s often expressed in person-months. 

So your RICE score is (Reach x Impact x Confidence) / Effort.

For example, let’s suppose an item in your backlog is a feature that will appeal to a new, additional target market, and that you’ve done extensive market research. 

The market research has shown a high likelihood that 900 new prospects will sign up for a free trial in the first month. So your reach for trial is 900. 

Your research has shown that prospects in the new market will be pretty excited about this new feature and that the impact, as measured by the number of conversions to paid licenses will be high. You decide to use Intercom’s scale for impact, and you decide to use “2” for high impact. 

Your confidence level (based on research) is medium to high, but you don’t want to go overboard, so you use a confidence score of 80%. So now you have all the contributors to the numerator.

(900 x 2 x 0.8) = 1440

For the denominator, your team has estimated the effort will take five person-months, so your effort score is 5.

RICE score 1440 / 5 = 288

If you keep the scales the same for all potential new features (which you gotta do) you can score all the other potential items in the same manner. You end up with a prioritized backlog.

The benefits of using RICE are that it removes bias and encourages data gathering for prioritization. And because it uses a consistent metric system, you can share your rationale with others (especially if you all apply it in the same way).

Cons of using this method are that it can be misused, or subjective unless you carefully define the meaning of its factors, like reach and impact. Gathering data can be time-consuming. And although RICE gives you numeric results, it may be hard to represent subjective data, like customer feedback.

3) Kano model 

The Kano model begins with the premise that user loyalty is based on the emotional response to product features. It classifies and measures a potential feature’s customer delight vs the cost or investment to implement it. Features are grouped into five emotional response categories: 

• Must-be (mandatory)
• Attractive
• One-dimensional
• Indifferent
• Reverse.

Mandatory features are required. For example, if you are developing a banking app, users must be able to view their transactions and account balances.

Attractive features add value. Using our bank app example, it would be nice to give users a bonus for performing transactions in the app. 

One-dimensional features increase customer satisfaction; it makes the difference between a satisfied user, and one that’s not. The better the feature performs, the happier the customer. 

Indifferent features, such as changing the programming language used to develop an app, don’t directly impact your users.

Reverse features make a user unhappy. Using our banking app example, if, when logging in, the user needs to both enter their password and answer a security question, they may become annoyed.

When using the Kano model, you need to deliver basic features, must-have, attractive, and one-dimensional features. To do that, you need to know what your customers value. A standard Kano questionnaire is available to gain quantified user feedback about current and potential product features. 

The benefit of using the Kano model is that the features selected are based on the emotional effect they have on users. It’s useful when your time and resources are limited and you need to make quick roadmap or backlog decisions.

But to use it, you need to classify features before prioritizing them, and that can take time.

4) MoSCow method

The MoSCow method is a prioritization method that uses the categories “must have,” “should have,” “could have,” and “won’t have.”

Must-have features are features you shouldn’t bother to release the product without. Let’s consider a grocery store app allowing users to place delivery and pickup orders. Users must be able to view the products and add them to their cart.

Could-have features will add value but are not required at the time of the release. The grocery app could allow users to specify a substitution for out-of-stock items. It’s not required, though – the grocery store could have the person shopping the order contact the customer about out-of-stock items and possible substitutions.

Won’t-have features are features that won’t be included in the product at this time. They can be added to the backlog for future consideration. Our grocery store app might not allow users to change their delivery or pickup times at this time through the app, yet.

A benefit of the MoSCow method is it works well with agile software development. It helps speed up product delivery. Tasks are prioritized based on resources.

A disadvantage of this method is that it can be challenging to gain consensus on the product team when many stakeholders are involved.

5) Value/effort score 

To use the value/effort score method, you need to determine the value each feature adds and the effort it will take to complete the feature.

Value calculates how a task contributes to the goal by assigning points to each level of effort.

The effort calculates how much effort it will take to accomplish the goal. Consider t-shirt sizing to give an estimate, and assign points to each size.

Calculate the priority by dividing the value by the effort.

The benefits of the value/effort score are that it is easily customizable and doesn’t involve any complex calculations.

A con of the value/effort method is that it’s very subjective.

6) Cost of delay method

The cost of delay method involves determining the cost per unit of time of not implementing a feature. It is usually measured in dollars.

There are different ways of measuring the cost of delay, sometimes called profiles.

Fixed date is a method that involves a date that cannot be missed. For example, during the Y2K problem, software needed to be updated before 1/1/2000. If developers did not make the code changes by that date, it would be useless (or disastrous). There would have been no point in making the updates in 2000. (The planet would have already exploded from all the software failures).

Expedite means the cost of delay is significant, and the fix needs to be implemented as soon as possible. For example, if a store website has an issue with the login page, every minute it is down, customers may go to a competitor to make purchases.

Linear means that you are losing a fixed money every day you don’t deliver a feature. An example is if your store doesn’t offer a product your competitor has. Shoppers will take their business to your competitor.

The benefits of this method include helping to allocate resources effectively because you can use it to select and then sequence the work they need to perform. It is useful when developing a competing product. If speed to market matters, for example releasing a product or features before a competitor does, it may be the right technique.

However, this method requires an accurate estimate of both the duration to develop and the impact on revenue if you don’t. Also, it isn’t at all focused on customer satisfaction – it’s one-dimensional, focusing only on the repercussions of delaying a product, or feature.

7) Weighted Shortest Job First 

The WSJF method is used to sequence your work based on rapid economic benefit. It requires calculating the relative cost of delay divided by the relative duration (or level of effort or job size). In this sense “relative” means using a scale rather than actual numbers to compare features and other product backlog items to one another.

The cost of delay is calculated by considering three factors: user-business value (how much do your customers want this feature), time criticality (is there a fixed deadline, or will customers wait for this feature?), and risk reduction or opportunity enablement.

The benefit of this method is that it delivers maximum economic return fast, and continuously. It prioritizes the backlog items by focusing on the features that enrich you most with the least effort or shortest time. It’s like eating dessert first - all taste and no nutrition. But to your bank account, it’s delicious, and quite nutritious.

It works best in flow-based environments (like Lean product development) where you’re continuously reprioritizing (and re-sequencing) work to deliver the most value in the shortest time. 

It’s also important to use it only on backlogs that contain similar items, that are each big enough to make it possible to determine economic benefit. (Hey, user stories probably aren’t big enough for that, but epics, and maybe major features, are).

WSJF technique is not suitable for smaller features or stories where, by themselves, the economic benefit can’t be determined. And, of course, it only works in continuous flow situations. 

Backlog prioritization techniques best practices

Let’s take a look at how to implement backlog prioritization.

Select the prioritization technique

Think about which technique works best for your type of product and backlog. For example, if you have two hundred features in your product backlog, stack ranking might not be for you (and you might want to hire additional staff to get your backlog caught up).

Determine buckets for each category

You will need to categorize your features. The method you choose will help you determine the categories to use. For example, the Kano model uses the categories must-be, attractive, one-dimensional, indifferent, and reverse. The MoSCoW method uses the categories “must have,” “should have,” “could have,” and “won’t have.”

If you set your values, such as in the RICE system for values such as confidence, define the values you will use and document them so they are clear for everyone. No one likes to guess what something means (and no one can explain or defend it).

Assign value to features

When evaluating features, determine what value they will add to the product. Look at them from different perspectives. 

Will this feature put us ahead of competitors? Is there a need not being met in the market right now that would put us ahead of the game if we developed it?

Will it save users time in their day? For example, when developing an app for curbside pickup, users who are doing a curbside pickup don’t want to wait twenty minutes for their order to come out. A feature that allows users to say when they are on the way could save them time. Or better yet, have GPS show how close they are to the store. The staff could get the order ready knowing they are en route to the store.

Assigns effort to features

To determine the effort each feature will take:

1. Don’t just guess.
2. Get input from everyone needed.
3. Pretend you are designing a feature for a grocery store website that will allow users to specify substitutions for out-of-stock products.
4. Consider who from the development team will be involved in working on this feature.
5. Use a relative scale, such as a Fibonacci series, rather than exact numbers if needed.

Business analysts will need to write the requirements. Developers will need to write code. QA will need to write test cases and test the code. Although your developers are nearly perfect, now and then a bug slips in.  

Be accurate (can you honestly do that?). And then pad it. Your team will thank you for not putting impossible timeframes on their tasks.

Re-evaluate your backlog from time to time

Not only will tasks be added, but you also need to re-evaluate older tasks occasionally to ensure they are ranked correctly in priority as needs change. 

Consider that you are developing a website for Max’s Grocery Store to allow users to place orders for pickup and delivery. At the beginning of your website development for Max’s Grocery Store, you determined it was okay not to build a feature to accept PayPal as a form of payment. 

Now, word on the street is that Groceries’ R Us up the road is accepting PayPal, and it’s a popular feature. It may be time to move that PayPal feature up to keep Max’s Grocery Store competitive. You might miss out on business opportunities if you never re-evaluate your backlog.

And, if you’re in a continuous flow environment, you’ll reprioritize your backlog more often than “from time to time”.

The PM’s hot take 

Look, techniques are aplenty and we are in no place to tell you which one beats out the other. Instead of telling you which one to use (which, you probably know by now, will be decided by the unique factors of the product you are working on), here’s a million-dollar idea: start dividing up your backlog by themes. The moment your backlog grows to an unmanageable size, there’s no saving you (or the backlog), so you need to split features, improvements, etc., into manageable chunks. Only then you can go in with your shiny prioritization technique and make that backlog sing for you.

Use Fibery to help prioritize your backlog 

As you work on prioritizing your backlog, consider using Fibery to make your job easier. While you can’t snap your fingers to make it turn into a genie to grant your every wish, it’s darn close.

Fibery supports backlog prioritization using built-in techniques including RICE, Value/Effort Score, MoSCoW, and Feedback references. But you can also create custom formulas for any technique of your choice for prioritization in Fibery. Or make up a new one. Fibery’s customization and reporting features allow for easy visualization of the most requested techniques, and any others you might want to use.

To try Fibery for free, sign up here. And if you love it, by all means, stay.