Agile Prioritization: Top-5 Techniques to Manage Your Backlog in a More Efficient Manner

Agile development methodology grants the developers immense flexibility in terms of the development process and allows to implement any changes at any time. The reverse side of the coin is that the project requirements aka the backlog need to be managed in an efficient manner and have strict prioritization in order to ensure the product’s functionality and satisfaction from the stakeholders’ side.

Prioritization of the requirements only sounds easy but in reality, there is much more to it than simply deciding what would go in the product and what would be left aside. A product owner (meaning, the person who manages the backlog) needs to consider the interests of the users, the development time, available time and resources and the stakeholders’ opinion when prioritizing the backlog. All that can cause quite a lot of stress but luckily, there are several prioritization techniques that make the backlog management easier.

The Kano model

The Kano model is focused on the product user and prioritizes the features correspondingly. The criteria that the model offers are as following:

• Must-be: these features are expected to be in the product and the customer often takes them for granted as something that “has always been there”. As well, these features add to the product’s functionality and must be included. In an e-commerce app, for example, that would be the option to add an item to the cart.
• Attractive: users do not expect these features but when they see them, they become extra-happy. Attractive features bring additional satisfaction but do not decrease it if they are absent. In the case of an e-commerce app, that would be an option to send a personalized card to a gift receiver.
• One-dimensional: this one is tricky because a product can work without these features but users expect them to be there. A perfect example would be a search icon in an e-commerce store: while it does not directly impact the process of buying (as a user can independently browse the store and find the item), customers will get incredibly annoyed if the search is not there.
• Reverse: these features tend to annoy the users so it’s better to avoid them. If we continue with the e-commerce app, such a feature might be an obligatory questionnaire before checking out. While marketers may think it’s a good idea to collect the users’ feedback right away, shoppers, in turn, will get annoyed that they cannot buy without completing the test.
• Indifferent: these features have zero impact on the customers’ satisfaction and can be left aside.

The Kano model is great for adjusting the product to the users’ needs. However, it does not consider the time and resources needed and might take too much time.

The MoSCoW model

This model is similar to Kano but is more product-focused. Here are the criteria that it has:

• Must: the absolutely obligatory features that impact the product’s success. If you can’t include them, you can cancel the project.
• Should: these features are on the second place after the “Must” ones. Though not vital, the “Should” features should actually be implemented in the feature once the team is done with the obligatory ones.
• Could: the “nice to have” add-ons that do not have any significant impact on the project’s success. At the same time, these features are small-scale and do not demand much resources or time so they can actually be done if the team has time/resources left.
•  Won’t: these features are of low priority and can be rescheduled or even omitted.

As said above, the MoSCoW model is focused on the product and its delivery while the Kano model focuses on the user. Thus, it’s a good idea for Agile teams to combine both models for the optimal result.

The Walking Skeleton

The Walking Skeleton is perfect for prioritizing the features for MVP development. And, since many clients prefer developing an MVP first, it is recommended to take this model into consideration.

The main goal of the Walking Skeleton model is to ensure that the MVP will eventually “walk”, meaning, it will function in accordance with the requirements. Thus, if you evaluate the features by this model, you will need to identify the following:

• The must-haves that make the system work,
• The ones that should be there in correspondence with the requirements,
• The ones that resonate with the business goals and values,
• The ones that passed the tests.

If you select and realize these features, you will receive a functioning MVP as an outcome. On the other hand, this model does not imply selecting any add-ons or prioritize other important features so you will have only bare functionality at your disposal (which is suitable for MVP release, though). 

Cumulative voting

When selecting the features to be realized first, you need to consider the interests of the developers, designers, stakeholders, and any other parties involved. In order to achieve mutual agreement, product owners often use the cumulative voting method.

This method of feature prioritization implies gathering all the involved parties together. Then, each person is given a certain number of imaginary credits (like 100$, for example). The main task for every person is to distribute this credit among all the features. Once everybody does so, you can calculate the total number of units for every feature and thus, identify the ones of the top priority.

Though this method is not very suitable for identifying the features that are crucial for the system’s functioning or bringing value to the users, it can be useful when resolving a disagreement between the parties.

Prioritization matrix

The Agile prioritization matrix is a great way of prioritizing the features by weighted scoring. In this method, the prioritization is unbiased as the features are prioritized by assigning a calculated score to each. Here is how to create a prioritization matrix.

Step 1: List down the features that need to be prioritized.

Step 2: List the criteria that you will use for the features assessment.

Step 3: Assign the weights (a certain percentage) to each criterion. The total sum of all the weights should be 100%. For example, if you have three criteria (ease of implementation, cost, user-friendliness), you can assign 20%, 50% and 30% to each so the total would be 100%.

Step 4: Now, evaluate each feature on a scale from 1 to 100 for each criterion. For example, the cost of realizing the feature #1 would be 60 out of 100.

Step 5: Multiply the score of the feature by the weight percentage of the criterion. Say, you gave 60 to feature #1 in terms of its cost and you assigned 50% to the cost criterion. So you will do the following: 60 x 0.5 = 30.

Step 6: Repeat the process for every criterion for every feature and sum all the multiplied scores together.

Create the prioritization matrix in a table for better visualization. As an outcome, you will have a calculated priority score for every feature and you will be able to easily compare them. 

Summing up

The choice of a suitable Agile prioritization technique will heavily depend on the project scope, business goals and the interests of the parties involved. It is usually a good practice to combine a few techniques together in order to maximize their value and achieve the most accurate result in accordance with the requirements.