Best practices to order your product backlog

A backlog should be ordered. The Product Owner is the one accountable for ordering these backlogs. But how should the priorities be determined? In this article, we’ll take a look at some common practices, ranging from manual ordering, to formulas, to aspects worthwhile to consider.

Manual ordering

“Maximize the amount of work not done.” If everyone puts their full trust in the PO to do the right thing and if the PO doesn’t need formulas or other magical calculations to do so, why bother with policies and formulas? The answer is: you just don’t. As with everything Agile: the fewer rules you need, the better, as long as it doesn’t come at a cost.

So what are the risks of manual ordering? First off, there is having to explain your reasoning behind a certain order every time you are prompted to do so. If you are being questioned a lot, having to explain yourself can be cumbersome and time-consuming. Furthermore, you have to firmly trust yourself. After all, you are making your decisions on a subjective basis. This will be the case for all ways of ordering your backlog, but most of all, for manual ordering. For each decision you make, ask yourself why and consider all angles.

So how do we avoid these risks and increase the level of transparency?

Formulas

The most objective way to order product backlog items is to assign each of them a product backlog score (PBS) and to make it fully transparent how that PBS was calculated.

How to set the PBS is completely up to you. You can gather input from the people who do the work (Lean!) and from the people you’re doing the work for. You could even let them directly set certain scores (such as system architecture and other examples, found below). Make sure at that point, though, that you still review the scores, as people will often assess items in different ways.

Whatever you do, the best approach is to always make it transparent which aspects you consider and what score you gave them.

So what formula do you use? Again, it is completely up to you as a Product Owner to determine what delivers the most outcome consistency. You could simply sum up different aspects, but you can also make your formula more complex and precise by assigning weights, multiplying, dividing, etc.

Now, what aspects should we consider and why are they valuable?

Considerations

Achieving proper prioritization is not easy. It requires clear goals, a focus on the outcome, and constant inspection and adaption. Key factors you could consider include:

• Customer satisfaction
• System architecture
• Business value
• Cost-benefit
• High complexity, high level of difficulty, highly time-consuming, and high risk
• Frequency of use

Customer satisfaction

Give priority to things that will help the customer realize their return on investment (ROI) and will thus increase the level of satisfaction.

This could be set by the Product Owner with input from the customer, but could also be set by the customer directly. In the latter case, if you have multiple customers for the same product, make sure to offset the scores so they average to the same number. It’s important that this shows the priorities of the customer themselves and not the differences between the various customers (see below).

System architecture

Features with a large impact on system architecture should be addressed with higher priority. Any change in these areas will cause changes in other parts of the product and thus lead to reworks. If you postpone this, the amount of refactors you will need to do will continuously increase because of added features during that time.

Business value

Some factors may be important for the customer, whereas others will give you an edge over immediate competitors. It’s up to you as a Product Owner to determine whether requests by the customer, the CEO, the marketing team, or even others have more business value.

Important to note here is that this is just one of many considerations to make. Business value is not the be-all-end-all of factors to consider, like many believe. An alternative is to combine the “customer/project priority” aspect of this with the customer satisfaction, discussed above. This gives you the winning combination of both focusing on the right thing while simultaneously reaching the right people.

Cost-benefit

A very popular way of prioritizing is comparing the value (see items discussed above) to the cost of implementation and, consequently, putting the higher-cost items at the bottom. While there is much to be said for this type of prioritizing, be careful to not make this your sole consideration. Sometimes it is strongly advised to tackle higher-cost items first. More on that in the next item.

High complexity, high level of difficulty, highly time-consuming, and high risk

Applying higher priority to complex items will ensure that the best resources are properly allocated. Items that are difficult to implement should get higher priority to ensure enough time is provided to implement and optimize them.

The same goes for items that require more time to implement. A bigger item results in more uncertainty, and will furthermore probably require more time to make adjustments. This to avoid that important features are missed because of time constraints. Finally, giving higher priority to high-risk items reduces the overall risk of failure by the end of scope (budget or time).

Frequency of use

Features that are more likely to be used should have higher priority. Not only because it tends to indicate value, but also because there is more chance of getting valuable feedback on these, giving you room for optimization.

Self-manage

Ultimately, it’s up to you as a Product Owner to determine the best way to order the backlog. Even with all the information you have, you can only confirm the value something has once it’s delivered to the end user. So don’t be afraid to fail (early on) and request as much input as you can from both your team and stakeholders! Because in the end you are accountable, but that doesn’t mean you are alone in your endeavor.

And of course, as always, inspect and adapt.

---

You might also like