Blog, Pitang.

Did you know that there are more than 30 frameworks that help with Backlog prioritization?

It is important to understand that an unprioritized Backlog, or even one prioritized the wrong way, can pose a major risk to future deliveries. If there is no product evolution vision, you will most likely just have a bunch of user stories instead of a Backlog aligned with your product roadmap.

We also know that agile methodologies do not define the best way to prioritize the Backlog. Usually, this responsibility falls to the Product Owner, and many order their Backlog by Value—whether value for the business or for the user—through alignments or research.

Another very common way of prioritizing is by considering Effort. There is always the concern of making it “fit” into the Sprint, and in these cases, the team helps decide what is a priority.

Matters related to Dependencies—whether technical or functional—can also be considered.

Methods for Backlog Prioritization

OK, I have a Backlog, but how do I prioritize? What is the best method for each case? How can we have a truly prioritized Backlog that delivers value to the business?

To answer this question, we will do an exercise with some scenarios and methods that could potentially help provide a good answer to it:

1. GUT Matrix (Gravity, Urgency, and Tendency)

Often, the Backlog is infested with “issues,” and this list also needs to be prioritized. The Backlog does not live on new features alone.

All issues are urgent and, at the same time, they all seem equally important.

The GUT Matrix evaluates the attributes Gravity (of the issue), Urgency (to resolve it), and Tendency (to get worse). It helps mainly when we are dealing with a list of very similar issues.

2. Kano Model

When the focus is on wanting to increase customer satisfaction, the Kano model can help you.

The Kano Model is based on three pillars:

·        WHAT DOES THE CUSTOMER NEED?

·        WHAT DOES THE CUSTOMER WANT?

·        WHAT DELIGHTS THE CUSTOMER?

These questions are important to answer when we aim to have a Backlog prioritized to deliver what the customer is really looking for.

The method also helps reflect on whether your product already meets the customer's basic needs before even thinking about increasing customer satisfaction.

3. MoSCoW

When we are talking about MVP (Minimum Viable Product), our focus is on delivery and rapid testing. Feedback cycles will drive product evolution. Very useful when we want to validate the viability of a product.

Using MoSCoW, we make clear what is Must Have (MUST HAVE), what is Should Have (SHOULD HAVE), what is Could Have (COULD HAVE), and what is Won’t Have (not important at that moment for the delivery, that is, WON’T HAVE).

The MoSCoW method helps us prioritize according to what needs to be validated, focusing on what is essential for delivery.

4. RICE Score

Sometimes we have risks associated with deliveries, and this can be the focus of prioritization.

There are several types of associated risks, such as delivery risk, operational risk, and transition risk, among others that need to be evaluated.

It is very true that there are several spreadsheets and instruments to support risk-based prioritization. As an example, the RICE method uses 4 factors to evaluate each project item, considering Reach (REACH), Impact (IMPACT), Confidence (CONFIDENCE), and Effort (EFFORT).

Even before using it, consider whether you have reliable data on hand and which data will be used. Sometimes other methods, like Value vs. Risk, for example, may be more useful.

5. WSJF (Weighted Shortest Job First)

The WSJF method is potentially interesting when we seek to involve and consider Time to Market, which represents the time the company takes from the start of development to the delivery of the product for sale.

WSJF prioritizes the analysis of cost of delay and job size for each project. To do this, you must assign scores to the projects by evaluating several criteria.

• Business Value (BV): Evaluate how much value that specific project will bring to the business.
   

• Time Criticality (TC): This criterion should be evaluated according to the urgency of releasing the project's product.
   

• Risk Reduction or Opportunity Enablement (RROE): Here you should evaluate how much that project reduces the company's overall risk.
   

• Job Size (JS): This criterion should be evaluated taking into account both the effort required to carry out the project and the time to deliver it.

Well, it is important to make clear that there is no right or wrong, better or worse. What exists is what is best suited for each case. I hope you find the best way for your challenge!