Value-Based Prioritization

Prioritization is a foundational practice in Agile. To understand why, recall the second principle of the Agile Manifesto, which states that Agile teams must “welcome changing requirements, even late in development.” While this sounds ideal in theory, what happens when a new requirement is added to a project that is already working at full capacity? If the customer has not been prioritizing the work items, the team faces a dilemma: How should they “make room” for the new work?

In reality, the customer may say, "I want it all!" However, if the customer is able to clearly prioritize the items in the backlog, any new request can simply be inserted at the appropriate position in the backlog. Lower-priority items may then be deferred or even removed altogether to make room for the new, higher-priority work.

Value-based prioritization refers to delivering the highest-value work to the customer as early as possible. The customer or Product Owner (PO) is responsible for ensuring that the items in the backlog are prioritized according to the value they deliver. When new work items are added, such as change requests or defect fixes, the customer will assess their priority so that their value can be compared against the existing items in the backlog.

This prioritization is a continuous process throughout the project. Typically, the team will meet with the customer at the end of each iteration to re-prioritize the remaining work items. For example, they will ask, "Has anything changed?" or "Do we still want to implement feature B next?" These sessions serve as important checkpoints to ensure the work is progressing toward the project’s objectives. All new priorities are captured in the product backlog and reviewed again at the planning session for the next iteration. This helps ensure the team stays on track to achieve the desired goals.

By asking the customer what their top-priority features are, we gain insight into their motivations, risks, and acceptance criteria. When a team does not prioritize work based on the value it delivers to the customer, they risk overlooking the key factors that determine the success of the project.

Prioritization Techniques

There is no single prioritization technique that is best for Agile projects. Each team should choose the technique that fits the needs of their project and what works best for their organization. We will now explore some commonly used prioritization techniques.

1. Simple Ranking Model

One of the simplest methods for prioritization is to label items as "Priority 1," "Priority 2," "Priority 3," and so on. While this approach is easy to understand, it can present challenges - stakeholders often tend to mark everything as "Priority 1." If too many items are labeled "Priority 1," the model becomes ineffective. Customers or Product Owners rarely request a new feature and classify it as Priority 2 or 3, because they fear that lower-priority items may be dropped from the project. For the same reasons, using labels like "High," "Medium," and "Low" can lead to similar issues. If there is no clear justification for what is marked as "High Priority," we may end up with too many items in the "High" category - rendering prioritization meaningless.

2. MoSCoW

The MoSCoW prioritization model derives its name from the first letters of the following categories:

• “Must have”
• “Should have”
• “Could have”
• “Won’t have”, hoặc “Would like to have, but not this time”

The priority categories used in MoSCoW are more clearly defined and better grounded than simply labeling items as “Priority 1” or “High Priority.”

• "Must have" requirements or features are essential to the system; without them, the system will not work or will have no value.
• "Should have" equirements or features are important - by definition, we should have them for the system to work properly.
• "Could have" features are additional enhancements that provide tangible value.
• "Won’t have", or "Would like to have, but not this time," refers to requirements that are nice to have but not necessary - they can be included or omitted without affecting the system.

3. Monopoly Money

Another effective approach is to give stakeholders an amount of virtual money equivalent to the project’s budget and ask them to distribute those funds amongst the system features. This approach is useful for determining the overall priority of system components, but it may raise concerns if participants begin questioning other project activities - such as documentation - believing they don’t contribute much value to the project. The Monopoly Money technique is most effective when it is limited to prioritizing product or software features.

4. 100-Point Method

The 100-Point Method, originally developed by Dean Leffingwell and Don Widrig for various use cases, is another way to prioritize features. In this method, each participant is given 100 points to allocate to the most important requirements. Stakeholders can distribute their 100 points in any way they choose: for example, 30 points to requirement A, 15 points to requirement B, or all 100 points to requirement C if that is their only priority.

5. Dot Voting or Multi-Voting

This is another technique where each stakeholder gets a predetermined number of dots (or checkmarks, sticky stars, etc.) to distribute among the options presented, let's look at an example.

Imagine that the team has completed a brainstorming session to identify potential project risks. The outcome is a list of 40 risks that now need to be prioritized. Each person is given 8 votes to indicate which items they believe are the most important. These votes can be distributed in any way the person chooses - for example, one vote on eight different items, four votes on one item and two votes on others, or any other combination that reflects their priorities.

The facilitator then sums the votes for each item and creates a ranked list based on the number of votes received. The voting can be done either publicly or privately.

To decide how many votes each person gets, a common rule of thumb is to allocate votes equal to 20% of the total number of choices. So if there are 40 items to vote on, we calculate 40 × 0.2 = 8, meaning each person receives 8 votes to distribute.

6. Kano Analysis

This technique is used to classify customer preferences into four categories: Delighters/Exciters, Satisfiers, Dissatisfiers, and Indifferent. Project stakeholders can use these categories to understand how customer needs relate to customer satisfaction. Kano analysis can also help determine which features should be implemented to promote customer satisfaction.

Let's look at each category in more detail:

• Delighters / Exciters: These are features that provide unexpected benefits, novelty, or high added value to the customer. For example, a beautifully designed report interface with eye-catching 3D effects could be a Delighter - something exciting that surprises and delights the user. However, customer satisfaction does not decrease if these features are not included.
• Satisfiers: For features classified as Satisfiers, the more the better. These features directly deliver value to the customer. If these features are not implemented - or are poorly implemented - customer satisfaction will decline.
• Dissatisfiers: These are features that, if missing, will make users unhappy with the product or software - but including them doesn’t necessarily increase customer satisfaction. For example, the ability to change a password in the system might be considered a Dissatisfier.
• Indifferent: These features have no real impact on customer satisfaction one way or the other. Since customers are indifferent to them, we should try to eliminate, minimize, or defer these features wherever possible.

7. Requirements Prioritization Model

The Requirements Prioritization Model created by Karl Wiegers is a more mathematically rigorous method of prioritizing requirements compared to the other techniques we've discussed. With this approach, prioritization is based on the benefit, penalty, cost, and risk associated with proposed features. Each of these factors is rated on a relative scale from 1 (lowest) to 9 (highest). Customers rate both the benefit score for having the feature and the penalty score for not having it. Developers rate both the cost of producing the feature and the risk associated with producing it. The numbers for each feature are then entered into a weighted matrix that is used to calculate the relative priority of all the features.

8. Relative Ranking / Prioritization

Regardless of which prioritization model the team adopts, the ultimate goal is to gain a clear understanding of the relative priority of features. Sometimes, spending too much time debating which technique to use can detract from meaningful discussions about what truly matters. For this reason, teams may opt to simply list features in a relatively prioritized order - without assigning numerical levels such as 1, 2, or 3, or using labels like high, medium, or low.

Let’s look at a sample of a simple relative prioritization list:

In the diagram above, each feature is listed in order of priority. The items at the top of the list-features A through D - are part of the defined minimal viable product (MVP). If scope needs to be cut to meet the budget and schedule constraints, it's clear by looking at this simple list that adjustments should be made to item E.

Relative prioritization also provides a framework for deciding whether to incorporate changes. When a change is requested, the team can ask the Product Owner, "What items are more important than this change?" The new change can then be inserted into the prioritized work list at the appropriate point, as shown below.

If the project's time or budget has already been fully consumed by the current scope, then adding a new change will inevitably push a lower-priority feature below the cutoff point.

9. Paired Comparison

Paired comparison analysis is an activity to evaluate a set of requirements by comparing them against each other. This is a useful and simple technique to evaluate and rank requirements when the evaluation criteria are subjective. It is especially helpful when priorities are unclear, when the requirements are very different in nature, or when there is limited objective data to support decision-making.

Paired comparison analysis is usually performed with the support of a comparison matrix. This matrix must be set up to avoid comparing a requirement to itself or duplicating any comparisons. The process of performing paired comparison analysis is as follows:

• Identify the requirements to be evaluated.
• Identify the evaluation criteria to support decision-making (for example: the most important, the most valuable, or the easiest to implement).
• List all requirements along the left column and top row of the matrix.
• In each empty cell, compare the requirement in the row with the one in the column, then write down which one better meets the evaluation criterion.
• Repeat the process until all possible pairs have been evaluated.
• Count the number of times each requirement was selected as the preferred option.
• Rank the requirements based on the number of times they were chosen.
• Consider the requirements with the highest rankings.

For example, suppose a team wants to decide which feature to prioritize. They can use paired comparison analysis to support this decision.

Summary

There is no single best method for prioritizing features across all projects. Regardless of the technique used, be sure to watch for any issues that arise during the prioritization process, such as "lack of full team involvement" or "too many items labeled as Priority 1." The objective is to understand the relative ordering of features or requirements, rather than simply assigning category labels. From this understanding, we can build a flexible and adjustable list that can be reprioritized as needed. This flexibility allows Agile teams to remain responsive and deliver the highest-value features to customers within the available time and budget of the project.