Agile Prioritization Techniques - Expert's Top Picks
Agile Prioritization Techniques

Agile Prioritization Techniques – Expert’s Top Picks

Last updated on 13th Jul 2020, Blog, General

About author

Udhayakumar (Sr Devops Engineer )

Delegates in Corresponding Technical Domain with 6+ Years of Experience. Also, He is a Technology Writer for Past 3 Years & Share's this Informative Blogs for us.

(5.0) | 16935 Ratings 1368

Software development or any other project facing multiple requirements, budgetary constraints, and tight deadlines often necessitate the need to prioritize stakeholders’ requirements. At some point, it’s usually necessary to make decisions on which set of requirements need to be implemented first and which ones can be delayed till a later release.

Numerous methods on how to prioritize requirements have been developed. While some work best on a small number of requirements, others are better suited to very complex projects with many decision-makers and variables. This list of requirements prioritization techniques provides an overview of common techniques that can be used in prioritizing requirements.

Ranking

When you rank requirements on an ordinal scale, you give each one a different numerical value based on its importance. For example, the number 1 can mean that the requirement is the most important and the number n can be assigned to the least important requirement, n being the total number of requirements. This method works best when you are dealing with a single stakeholder as it can be difficult to align different stakeholders’ perspectives on what the priority of a requirement should be; taking an average can however, address this problem to some extent.

Subscribe For Free Demo

[custom_views_post_title]

Numerical Assignment (Grouping)

This method is based on grouping requirements into different priority groups with each group representing something stakeholders can relate to. For example, requirements can be grouped into critical priority, moderate priority and optional priority. Stakeholders may also classify requirements as compulsory, very important, rather important, not important, and does not matter in order to describe their importance.

These groups should be clearly defined so that stakeholders do not have a different understanding of each during the prioritization exercise. To prevent stakeholders from putting all requirements in one category, the percentage of requirements that can be placed in each group should be restricted. One disadvantage to this, however, is the fact that requirements in each group will then have the same priority with no unique priority assigned per requirement.

Moscow Technique

Instead of numbers, this method uses four priority groups: MUST have, SHOULD have, COULD have, and WON’T have. With this technique, stakeholders can prioritise requirements in a collaborative fashion. The acronym represents the following:

  • MUST (Mandatory)
  • SHOULD (Of high priority)
  • COULD (Preferred but not necessary)
  • WOULD (Can be postponed and suggested for future execution)

The decisions of stakeholders on requirements’ priorities are categorised as shown above. See MoSCoW : Requirements Prioritization Technique for more on this. 

Bubble Sort Technique

To prioritize requirements using bubble sort, you take two requirements and compare them with each other. If you find out that one requirement should have greater priority over the other, you swap them accordingly. You then continue in this fashion until the very last requirement is properly sorted. The result is a list of requirements that are ranked.

Hundred Dollar Method

This simple method is useful anywhere multiple stakeholders need to democratically vote on which requirements are the most important. All stakeholders get a conceptual 100 dollars, which they can distribute among the requirements. As such, the stakeholder may choose to give all 100 dollars to a single requirement, or the person may distribute the points more evenly. The higher the amount allocated to each requirement, the higher the priority of the requirement. At the end, the total is counted and the requirements are sorted based on the number of points received.

This technique should only be used when you have a small group of requirements to prioritize and when you have the same set of requirements to prevent respondents from influencing their results by assigning more dollars to their favourite requirement.

Kano Model

The Kano model is one of the most popular prioritization approaches. It was described in the 1980s by Professor Noriaki Kano.

Course Curriculum

Get Agile Certification Course to Take Your Career Next Level

Weekday / Weekend BatchesSee Batch Details

According to this product prioritization framework, the features are categorized in compliance with the needs and expectations of clients.

The original variant of the model classifies items in the following way:

  • Must-be items that are expected by your clients. These features will not amaze them, they just must be included in your product.
  • Attractive items that make clients happy when they are there, but do not upset them when they are not.
  • One-dimensional items that make clients happy when they’re there and unhappy when they are not.
  • Indifferent items that have no impact on clients satisfaction level at all.
  • Reverse items that make clients unhappy when they are there and happy when they are not.

This model helps companies that tend to only do Must-be features. In order to succeed in business, you definitely have to deliver attractive and one-dimensional features as well.

Opportunity Scoring

The Opportunity scoring model (or opportunity analysis) is the prioritization technique comes from Anthony Ulwick’s Outcome-Driven Innovation concept. According to the famous author’s theory, customers buy products and services to get certain jobs done.

Their feedback is still important, even although they are not very good at coming up with the solutions to their challenges. The team will use their feedback to come up with the desired outcomes.

The Opportunity scoring approach uses two graphs to measure and rank opportunities: Satisfaction and Importance.

After completing the list of ideal outcomes, you will be able to survey your clients, asking them the questions:

  • How important is a particular feature?
  • How satisfied are they with the solution?

Then you have to plot their answers on the chart, that will give you the opportunity to see the features that matter the most to the clients but currently have low satisfaction scores within your product.

These items will be prioritized for your next sprint.

ICE Scoring Method

The prioritization methodology named ICE was first described by Sean Ellis. The ICE model was initially intended to prioritize growth experiments. Nowadays it is widely used for regular project ideas.

ICE stands for:

  • Impact: How impactful will a particular feature be?
  • Confidence: How will the feature prove our hypothesis?
  • Ease: How easily can we launch this feature?

This prioritization approach is used among product teams and startups all over the world. Applying the ICE model includes the formula that calculates the final score of the feature value:

Agile Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download

Impact*Confidence*Ease = ICE Score

With this formula, you are able to represent your assurance in your evaluation by Confidence. The featured effect on the product is Impact. The easiness of implementation is Ease.

All you need then is to rate the entire feature request and choose the most valuable ones to implement.

Paired Comparison – In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.

Are you looking training with Right Jobs?

Contact Us
Get Training Quote for Free