Master 🥋 these 4 Agile Backlog Prioritization and Ordering techniques for Value Delivery

In the dynamic world of agile project management, efficient prioritizing is critical for successful product development. Choosing the appropriate prioritizing strategy may have a big influence on project success. Consider your backlog as an enormous treasure trove, with every Product Backlog Item (PBI) representing a brilliant diamond. However, unlike Lord Hanuman, you are unable to carry the entire mountain back to your town. Setting priorities ensures that the work of your team has the greatest possible impact, much like selecting the finest jewels.

In this article, we will delve into four popular prioritization techniques that resonate well with Agile’s iterative and value-driven approach.

But a word of caution before we begin.

⚠️Prioritization is a Product Backlog ordering method, but not the only method

The newer version of the Scrum Guide favors the term ordering to prioritization (“The Product Backlog is an emergent, ordered list of what is needed to improve the product.”) That’s because prioritizing individual PBIs can be misleading.

Prioritizing usually involves comparing PBIs individually, which often does not consider the overall impact of the backlog order on value or ROI. Instead, the Backlog should be ordered considering all items together and their dependencies, market conditions, etc. Nevertheless, ordering based on ROI may still be beneficial in specific situations, for example in a Fixed Price/Fixed Scope contract.

Ultimately, the onus to deliver a totally ordered product backlog lies on the product owner, with the mantra “inspect and adapt.” And s/he is free to use any criteria for that, e.g., ROI, technical or business dependencies, risk, value, etc.

With this clarification, let’s talk about the four prioritization techniques. We have selected two value-based (MosCoW and RICE) and two effort-based techniques (WSJF and Value Effort Matrix) for this article.

Throughout the article, we will refer to the following mini-backlog (Figure-1) for a fictitious personal finance app, MintMaster, where we have already estimated the development effort.

MoSCoW

Developed by Dai Clegg at Oracle in 1994, this widely used simple classification system aids in quick decision-making by categorizing PBIs into “Must-have,” “Should-have,” “Could-have,” and “Won’t-have” statuses (some also interpret W as “Wish”).

• Must-haves: the essential features, the foundation stones of your product. Without these, your product crumbles.
• Should-haves: important features that enhance the user experience and add value. They’re not deal-breakers, but they make your product shine.
• Could-haves: nice-to-haves that add polish and delight users. They’re the frosting on the cake, but not the cake itself.
• Won’t-haves: features that don’t align with current goals or resources. They might be tempting, but prioritize ruthlessly!

The MoSCoW technique helps teams focus on delivering essential features while providing flexibility for less critical items. Sadly, it doesn’t provide a numerical basis for prioritization, which may limit its applicability in data-driven environments. Moreover, different team members may interpret priorities differently, leading to potential misalignments. Pro Tip: Use a consistent scoring system in MoSCoW, like weighted scoring.

If we apply it to our imaginary backlog for MintMaster, we may prioritize it to look something like the following (Figure-2). Note that your justification for scoring can be be different than mine.

The charm of this technique is its simplicity. MoSCoW aligns well with Agile’s iterative approach by focusing on delivering the core value first, iterating, and adding others later. It also aids in stakeholder alignment, where everyone understands what’s critical and why.

RICE

RICE is an acronym for “Reach,” “Impact,” “Confidence,” and “Effort.” Commonly used for prioritizing features or tasks in product development, this technique was popularized by Sean Ellis, an entrepreneur, investor, and startup advisor known for his work in growth hacking and product management. RICE assigns scores to each factor, providing a quantitative basis for prioritization. The method is data-driven and flexible, but its effectiveness hinges on accurate estimation and a clear definition of “value.”

Here’s a brief overview of each component:

• Reach: number of users affected by the PBI. More users = more potential impact.
• Impact: positive impact on the business or users, in terms of (say) increased engagement, revenue, or user satisfaction.
• Confidence: certainty of achieving the expected impact.
• Effort: the development effort required to implement. Less effort = faster wins.

Let’s calculate the RICE scores for our MintMaster stories. We have used a scale from 1 to 10 for each factor, where 1 represents the lowest and 10 represents the highest. But you can use other scales. For effort, we have considered the Story Point estimates (Figure-1). We calculate the RICE score using the formula, as follows:

RICE Score = Reach * Impact * Confidence / Effort

While assigning the scores, you might need to consider several factors, such as the target audience, competitive landscape, market trends, and team capacity. For example, for User Story 3, I opined that while automating tasks adds value, its direct impact on core user needs (e.g., viewing balances, transferring funds) might be smaller compared to other features. I also considered that not all users might utilize recurring transfers frequently, potentially limiting their reach and overall impact.

Do note that it’s not necessary for RICE scores to match MoSCoW prioritization rankings for the same backlog items. For example, a feature that is deemed “must have” in MoSCoW prioritization might not necessarily have the highest RICE score if it has a limited reach, lower impact, or higher effort compared to other features. However, there might be some correlation between the two prioritization methods, especially if the factors considered in RICE align closely with the importance and urgency criteria used in MoSCoW.

RICE is an apt technique for enabling data-driven decisions rather than using gut feelings. Also, it considers both user impact and business goals, which is great for strategic prioritization.

Value Effort Matrix

This visual tool plots items on a graph based on their perceived value and effort. It facilitates quick comparisons and discussions, but the subjective nature of value assessment can lead to disagreements.

The 2×2 matrix has the following quadrants:

• High Value, Low Effort: They are the golden nuggets. These PBIs should be prioritized for quick wins and maximum impact.
• High Value, High Effort: The Diamonds in the Rough. Break down these massive PBIs into smaller, more doable chores.
• Low Value, Low Effort: The Pebbles. Consider delaying or removing these “filler” PBIs.
• Low Value, High Effort: The Coal in the Mine. Avoid these money drains unless absolutely essential.

Following is a possible visualization of the value effort matrix for MintMaster user stories:

Value Effort Matrix helps in visualizing the trade-offs between value and effort to identify quick wins and low-value items. Its also notable that RICE and the Value Effort Matrix cab be used collaboratively for informed prioritization.

Weighted Shortest Job First (WSJF)

WSJF is a prioritization technique commonly used in lean methodologies and frameworks like SAFe (Scaled Agile Framework). It aims to maximize the value delivered by prioritizing backlog items based on their cost of delay and job size. WSJF was popularized as part of SAFe by Dean Leffingwell and draws inspiration from lean principles, particularly the concept of minimizing waste and focusing on delivering the most valuable features or tasks first.

One of the key concepts in WSJF is the Cost of Delay, which refers to the impact of delaying the implementation of a backlog item. WSJF prioritizes backlog items with higher costs of delay, ensuring that items with significant business value or urgency are addressed promptly. WSJF also considers the size or effort (Job Size) required to implement each backlog item. Larger items may have higher costs of delay but may also take longer to implement. WSJF balances the urgency of delivery with the effort required, aiming to maximize value while minimizing waste.

The formula for calculating WSJF is typically represented as:

WSJF = Cost of Delay/Job Size

Higher scores indicate tasks that deliver more value per unit of effort. WSJF prioritizes these tasks, aiming for faster completion cycles and quicker feedback loops. Here is our MinMaster backlog prioritized using WSJF:

WSJF encourages a culture of continuous improvement by regularly reevaluating backlog priorities based on changing business needs, market conditions, and feedback from stakeholders. This adaptability is essential for Agile teams to remain responsive to emerging opportunities and challenges.

Here is a quick field guide to the four prioritization techniques we discussed:

Beyond the ⚙️ Toolkit

Choosing the right prioritization technique is a critical aspect of successful Agile project management. Each technique discussed has its strengths and weaknesses, and the most suitable approach depends on the nature of the project, team dynamics, and the desired level of detail in decision-making. By understanding the nuances of these popular prioritization techniques, Agile practitioners and product managers can make informed choices that align with their project goals and team capabilities. Just ensure to be transparent, get buy-in from stakeholders, and ensure everyone understands the priorities.