Backlog prioritisation methods
A prioritized backlog is important. Which method you choose is up to you and specific to the project. This is an overview about prioritisation methods and what to consider for a healthy backlog.
Estimate your backlog
In a previous article Backlog estimation done right, I have discussed why you should estimate, and why not. If you want to know more about estimating backlogs, you might want to read that first.
Why prioritize your backlog?
Teams rely on a prioritized backlog to know what to pick up next. The backlog should be ordered by importance, so the most important items come first, and less important items come later. A healthy backlog is a key success factor of your project.
Having no specific order in the backlog because everything is „very important“ means nothing is important. The chance of not delivering the right pieces first is high.
Often people try to push their feature requests and complain about delays. This is often a reason for missing visibility. If you have a backlog, which is visible to all relevant stakeholders, people will know that their feature request has been considered and at which time in the process.
Adding new backlog items
In your next sprint planning, you choose your top items from your ordered backlog. After agreeing on a certain amount of backlog items, the list of included items is fixed. The team agrees on doing their best to get everything done in the given time frame. The product owner agrees on letting them only work on what has been set.
While in the sprint, the team as well as the product owner can add anything new to the product backlog, which will be considered in the next planning. The sprint is fixed, so under normal circumstances, new backlog items will not be accepted to the sprints backlog.
This is one of the major benefits of Scrum: within these Sprints, the team can concentrate on the specified backlog items without being disturbed by further negotiations about new tasks.
The main reason why we face negotiations about new „urgent“ tasks is primarily because stake holders do not understand the process enough. This should lead to additional training and communication, so they understand the benefit of prioritizing a backlog and defining sprint goals for higher outcome.
Add bells and whistles
Stakeholders will always get back with new ideas, special features or will just wish for nice gradients on buttons. And of course make the Logo bigger.
The thing with features requests is… They’re just added to the backlog. So when adding priorities to the backlog items, most likely those items with the higher values are chosen first. Backlog Items with a low value might just drop out of the backlog at some point.
When to prioritize
Ideally there is a continuous prioritisation process of the backlog. In Scrum, there is the Backlog Refinement Meeting, which I suggest should take place in regular intervals like in the middle of the sprint. It is meant to provide room for estimating backlog items and putting them into the right order.
At the Sprint Planning, the Product Owner will provide an ordered product backlog to choose the next stories from. Ideally the order of items has been done already, so the planning is only about how much can be included in the sprint.
Wo is prioritizing the backlog?
The Product Owner is responsible for providing an ordered backlog.
Of course, the Product Owner can always include the team into the process for better insights as well as stakeholders for their external view. It makes sense to have members from the development team taking part, as they will more likely be able to also provide insights on the size of the items.
How to prioritize a backlog
There is no simple answer on which method to choose from. It really depends on your specific case. Things to consider when ordering your backlog:
Value: Value in this case means business value: How much is that feature worth related to the final product. Is it important for your customers? Do you need that feature to launch your product? Are you able to acquire more users with this new feature?
Risk: If you face difficulties, face an unknown technology stack or you are uncertain if your users are interested at all in your new feature? If this is critical to your product, you might order your backlog and work on items first, which put your product at risk. Validate these issues quickly might put you in a safer and more controllable position.
Dependencies: In the ideal world, each story you have in your backlog is an independent piece of work. In reality, you are facing dependencies between tasks. You might need to order your backlog accordingly.
You might prioritize by value or by risk. You might do it strictly along a certain method, or just by your personal preference. Even combining various methods is reasonable. Consider that prioritizing a backlog might also depend on many external factors, such as external stake holders like investors, managers and users of the product.
What to include
Of course the backlog includes all sorts of different kind of items.
Features: You will most likely have many features requests, ideally they are represented as user stories.
Bugs: Hopefully you have not many of those. Consider fast lanes or anything like that to cope with these in a quick way if necessary.
Technical Dept: Don’t forget about that. If you need to refactor things, clean up, add documentation etc., just add backlog items for it, so it can be considered in the next sprints.
There is actually a good book about a real live example on this topic at the Swedish police:
These are a few methods I want to mention. There are more if you do further research. But I guess there is no holy grail in prioritisation methods, and you have to choose among them, combine them, and develop them to your own needs. So consider this more like a kind of starting point.
MoSCoW: Must, Should, Could, Won’t. Distribute all features along these tags, and go for mustfeatures first.
Business Value Based: With this method, higher value is produced first and in a shorter time frame.
Technology Risk Based: If there is a risk in the chosen technology, you build that first to make sure, you are on the right track. Better validate early if the chosen technology works out or not.
Kano Model: This model provides a prioritisation of features based on the preferences of your customers. Share your priorities between mandatory items, useful things and exciting new features.
Walking Skeleton: Build a minimal selected feature set implementing end-to-end features in a very short time span.
Validated Learning: Features are chosen based on the highest market risk. You release new features very early to validate your project and to be able to make good decisions based on market feedback.
Cost of delay: Deliver early and often. Analyse what features will delay the process the least, and order the backlog along that.
Theme screening and Theme scoring: Work out a few different criteria for the next release. Compare the user stories against a story which is defined as a "baseline theme", a sort of medium story according to those criteria.
A prioritized backlog is important. Which method you choose is up to you and specific to the project. I will shed light on a few of the above mentioned methods in detail in the coming blog posts. If you want to know about a specific method please tell me, so I can consider it.