How to prioritize your backlog
A method created through best-practice
Prioritizing backlogs can be a cumbersome and difficult task. It is difficult because it is a pure decision making process: what do you want to spent effort on for the coming period, and more importantly what not. Every person looks at a backlog with a different perspective: sales wants to have new features as soon as possible so they can sell those to customers, customer care wants to have the most pressing issues resolved, UX wants to have new screens and flows implemented, etc. In an organization people have different interests and different agendas and it can be difficult to keep everyone satisfied. In my experience it can be helpful if you can make motivated choices why you prioritize certain activities above others.
In this article I’ll describe a method that can help you to prioritize your backlog.
When to use this method?
The method described here can be used to prioritize ‘Epics’ or ‘Features’ on a backlog. Even though I’ll refer to the term “business case” it is not a business case in the traditional sense. The prioritization method described here is applicable mainly for existing products for an existing development team. To set up a new product or new business line completely different stakes may be involved.
The foundation: Weighted Shortest Job First
The method that I’m using is based on the ‘weighted-shortest-job-first’ (WSJF) principle. This is a principle that is used in agile software development. It states that if you have to prioritize based on one element you should look at the ‘cost of delay’ for a feature. Instead of trying to answer the question “what brings us most value”, which — in my experience — can often lead to a battle between products/features/departments of who dares to bet highest, we reverse that question and ask the question “what do we lose if we don’t do this now”. And as a result the biggest loss should be dealt with first.
Let’s take an analogy to understand this reasoning: Imagine that you are stranded on an island what do you care about first? You are not looking for the biggest gain for your life, but you care about minimize the loss. Your list of priorities is evident: 1. Find food. 2. Find shelter. 3. Keep warm. You can’t really be bothered with anything else. A similar logic applies to product development. If we don’t make feature A, we will lose existing customers. If we don’t make feature B, we will lose the big prospect. If we don’t do feature C, we will lose the potential to up-sell. Which of these risks needs to be dealt with first?
What criteria to look at?
Obviously product development is not a life-and-death situation. What are then the criteria to look at? These criteria can be different based on the business that you are in. I’ll describe a few criteria below that I typically use. It is fine to add one more criteria, or to slightly change one of the criteria below. In general I would recommend not to add too many criteria. Let’s say that 5 would be really a maximum for me.
These are the criteria that I look at:
- Business value
- Urgency
- Opportunity
- Development size
Business value
When we develop this feature, epic or part of the product what is the economic business value. Will this bring in additional money, or will this make existing customers spent more money? Or will this prevent us from losing money, because people will start using competitor products?
Think about this in a broad sense: this can relate to pure sales, can include up-selling or cross-selling, but it may definitely also include optimizations to the way of working or throughput. If this feature means that your support organization suddenly has 10% less work that is a great result. Or if it means that you can process twice the amount of requests with half the effort (hardware/people/etc) that is great.
Examples of improvements with a high business value:
- Launching a premium version of a feature that is expected to generate a certain amount of revenue.
- Automatically invoice customers, and send reminders about unpaid invoices
- Storing data in a central place so people don’t have to spent time keeping files up-to-date
Urgency
How urgent do you have to deliver this feature. Have you already announced this feature somewhere? Have you already made this part of a contract? Is there a clear deadline or window of opportunity coming up ? If you have a big launch event coming up where this feature plays a major role, the urgency is high. If something remains broken until you pick up this task, the urgency is high. A competitor has just launched a new feature, and your customers are leaving you: urgent! This is what I’ll call the “broken lightbulb” state: you have to do it now or you’ll be in the dark. On the other side of the spectrum are items that do not really have a deadline, or that deadline is far into the future.
Examples of urgent things:
- Upgrading your app to support the latest Android and iOS version, because it breaks on the newest release
- A large fair or exhibition is coming up with a lot of potential new customers where you want to show your new feature
- A customer has signed a contract for which you promised a feature and that customer will be on-boarded soon
Opportunity
What is the opportunity that this new feature enables. Opportunity can be quantified in terms of size (there is a big addressable audience for this) and in terms of time (when the target audiences can starting using this). You should factor in both elements to determine how big the opportunity is. You may have a feature that benefits 100% of your target audience, but it can only be enabled after everyone has upgraded to the latest version — which you know takes 3 months. On the other hand, if you can automate a small process step in your organization and you only need to inform one person that is a gain quickly.
Examples of big opportunities:
- An improvement to your existing product or service that can be used by all of your existing customers
- Entering a new area or region with an existing product
Development size
How much effort is required to create this item. Typically this will be measured in sprint sizes, or money. It is a rough estimation of how much work has to be done to bring this feature to life. I usually estimate this in development sprints, because that is the “currency” that I work in.
Sizing the criteria
Once you have identified the criteria you want to prioritize your features on the next step is to give an estimation for each criteria. In traditional WSJF prioritization you compare all the items relatively to each other using Fibonacci-inspired numbers (1, 2, 3, 5, 8, 13, 21,…). What this means is that you give the smallest item a 1, the next smallest item a 2, etc. My experience is that this works fine if you have a small list of items, but in the organizations that I’ve worked in we’ve always had a list of 10+ items to prioritize, and oftentimes a list of 25+ items to look at. Therefore I’ve created buckets to represent the estimation numbers. I’m only using the values 1, 2, 3, 5, 8, 13, 21 because that gives me enough flexibility and variation to prioritize. I find anything above 21 is too uncertain to estimate anyway.
Business value, Urgency and Opportunity all have a scale where a higher number is better.
For example for Business value you could state that a value of 1 means that it contributes between €0-€9.999 annually, 2 contributes €10.000-€49.999 and 21 contributes >€1.000.000 annually (or whatever scale makes sense for your business). Make sure that you create enough spread within your range so you can really differentiate those criteria. Something with a 1 should be really small, and something with a 21 should be really, really significant.
For Urgency I’ve split the buckets up to start with 21: has to be done in 2 weeks to 1: can wait another year. The values in-between represent levels of urgency in-between following the relative scaling, so 13 means: has to be done in a month and 2: has to be done between 6–12 months from now.
For Opportunity I’m using more or less the same time range. 21 means: can be used the day after release, because it will be directly available to everyone, and it is clear who will be using this feature. whereas 1 means that it is not clear who will be using this feature, nor when. When you are sizing the opportunity also take into account how much the addressable audience is validated. Is this based on assumptions, or are there reports available on market size.
For Development size I always use sprints as my reference, since we have a team that works in sprints of 2 weeks. However, you could also add monetary buckets, or amount of people (FTE) that need to work on the feature to it, that is up to you. 1 represents <1 sprint and 21 represents somewhere between 5–10 sprints (about half a year full-time work for the team). Please note that the scale for Development size is reversed: small features have a low value and big efforts have a high number.
Comparing apples and … apples
Now that you have estimated all your feature along these criteria, you can easily compare which of the features has the highest priority. To do this we use the same formula that we use in WSJF. We sum Business value, Urgency and Opportunity and divide that by the Development size.
(business value + urgency + opportunity) / development size = priority
A higher priority means that it is more important.
But why take such rough estimations to prioritize developments? Essentially all of your estimations are based on assumptions. It doesn’t make sense to try to pin it down to detailed figures. You may have overlooked certain aspects, or not have completely thought through all involved aspects. Making it more precise creates the illusion that you can completely control your backlog and prioritization…which eventually you will learn is an illusion.
A practical example
Let’s consider that we are comparing three features to each other. Feature A is something that sales has requested and will certainly bring in a new client with a value of approximately €1.5 million (estimate it at 21). But, it’s not really urgent and we can deliver it within 3–4 months from now (estimate 5). The addressable market is rather high, but we still need to get some process into place in order to deliver it, so let’s estimate it at 8. You’ve checked with the development team and it will take them about 3 to 4 sprints full time to implement, test and release it so we estimate it at 8. Total priority: 4.25.
Another feature has been requested by your development team. They really want to optimize their workflow to optimize invoices by automatically creating invoices every month. In the current situation invoices have to be checked manually, and sometimes developers have to correct them. It’s not going to deliver a lot of additional revenue, so business value is 1, but it’s highly urgent because it has been a mess with invoicing (valued at 21), and we can directly use this for all customers (opportunity: 21). It will take approximately a full sprint for the team to work on this. Total priority: 21.5.
The last feature is something that you really believe in. It will create the opportunity to cross-sell another product in your product range, and you estimate it will boost sales of both products by about 10%. Business value is about €200.000 extra revenue per year, so we estimate it at 5. It’s not really urgent, because both products are selling fine, but it would be nice to have this feature in about half a year from now (urgency: 3). Furthermore you know that the target audiences for the product overlap about 5–15%. Therefore, the opportunity for cross-selling you estimate at a 3. It will take approximately 2–3 sprints to build it, so you estimate it at 5, giving your feature a priority of 8.4.
Your final prioritized list of features will tell you that you should work on Feature B first. As a whole this feature will cost your organization least and thus deliver most value.
Benefits
There are various benefits to using this method to prioritize the items on your backlog:
1. You have a clear rationale on why you are working on certain tasks and can share this to stakeholders in your organization.
2. It enables you to balance the interests of different parts of your organization. It can be difficult to balance the interests of sales with big new clients, development teams that want technical depth, senior management that have “great ideas for new features”, customer support that handle customer complaints, and every other part of the organization. It makes it visible to yourself and the organization that you are considering all perspectives.
3. You can reduce the importance that money typically is given in an organization. There is a tendency within many organizations to focus on monetary value, or give that priority over other aspects. However, that leaves a lot of additional ‘costs’ hidden. If you can take a small step to improve your everyday running activities that has great value compared to something you have to create from scratch in an organization that is not ready to deliver it.
4. The method helps you to break down items into smaller steps and helps to reduce uncertainty. As you can see from the calculation: development size is a key influence on the final priority outcome. If you manage to split the feature up in smaller features, it immediately rises in priority. For example, if you would break up Feature A in 2 features, which deliver a business value of 13 (about half the original estimate), but those are both estimated to a development size of 3 (assuming urgency and opportunity remain the same) your priority for those features rises to 8.7.
5. You can easily convert your backlog into a roadmap, because you estimate the size of every feature. Simply start from the top and place the features one after the other with the given development size. That should give you a rough timing of when to expect new features.
Some final thoughts
In this article I’ve described a way to prioritize feature development within an organization. The method is inspired by the weighted-shortest-job-first principle used in agile software development. I’ve laid out four criteria to estimate for every feature (business value, urgency, opportunity, development size) and given examples of how to size those criteria. Of course there can be additional criteria added that may be highly relevant to your organization. My recommendation would be to limit the number of criteria to 5 maximum. That will help to focus on the most important criteria for your feature development.
It may be tempting to make changes to the range I’ve laid out, or to make the criteria relatively more or less important, for example by multiplying them by some weighing factor. I strongly advise against that. You should take criteria that are equally important to your organization. If you cannot find criteria that are equally important, this may not be the method for you. If you really find an important motivation to make one criteria more important than the other criteria, then I would recommend to add additional buckets above 21 (34, 55, 89 for example). That will give you the opportunity to use those extreme values when necessary, but leave the relative importance of the criteria intact. (So don’t do 1.5 x business value + 0.9 x urgency + 0.6 x opportunity or something along those lines!).
Re-prioritize often. Priorities change, because the world changes, your insights change, customers change. The reason to agile development is to have a method to deal with those changes. The same applies to priorities in backlogs. Something that may seem critical to do now, may change next week. My recommendation would be to look approximately 2–3 months ahead at most.
Higher means less accurate. The beauty of this method of prioritizing is that it clarifies which items have a high degree of uncertainty. Higher values have a lower precision, because they span a bigger range. What that tells you is that those numbers are more uncertain. A value of 13 or 21 should trigger you and you have to seriously question whether you can’t split that up to make it more manageable. That also counts for development size. If you can split it up in smaller pieces those pieces become more manageable, and more accurate.
Enjoyed this article?
Please find my other articles under my profile! If you join Medium.com now you support thousands of independent writers around the world.
Remco Magielse is a product manager at CM.com. CM.com is a high tech company focusing on Conversational Commerce in The Netherlands. He has worked as a system engineer and product manager at Philips Hue. Remco has gained his Ph.D. on the dissertation titled ‘How to design for adaptive lighting environments: Embracing complexity in design’. He writes articles about product and software development, and the hard- and soft-skill required for product management. He is passionate about innovation and has contributed to approximately 50 patents.
