The Most Popular Prioritization Techniques and Methods to Use

During the most recent years, products global IT (and not only IT) companies produce become increasingly complex and advanced in terms of capabilities. In turn, it becomes more and more difficult by the day to point out the most important, fundamental requirements on the stage of production. Thankfully, there is a number of well tried-and-tested prioritization techniques to make your and your team’s lives at work easier. 

What are Prioritization Techniques?

Techniques of prioritization are a set of multipurpose algorithms based on the assessment of risks that help identify the least and the most expected features of the product in development (judging it from the consumer perspective). 

Top-5 Prioritization Techniques

Now, let’s take a look at 5 such techniques that can help you form the most efficient and proper sequence of requirements’ fulfillment when working on a certain product.

MoSCoW

The MoSCoW technique is an abbreviation of the four fundamental indicators of a requirement’s importance:

• M – MUST: defines requirements that must be met either during the last stages of product development or upon its release (this goes for pretty much everything your regular MVP should have);
• S – SHOULD: highly prioritized requirements, which, however, aren’t urgent;
• C – COULD: this group includes requirements to be met if a team possesses sufficient resources to meet them at all;
• W – WON’T: and these are the requirements that don’t correspond with the existing client goals or consumer audience preferences so that their implementation can be postponed until the work on later versions of the product.

Obviously, you can use these indicators properly and efficiently only after thorough market analysis, in particular, a focus group research. 

RICE

RICE is another abbreviation that describes four assessment criteria for defining the level of importance for certain requirements – much similarly to the previous position in the top:

• Reach: indication of a number of existing clients or unique transactions during a particular timeframe;
• Impact: describes how much a certain feature can change the level of profitability/popularity of an end product – insignificant, significant, essential (project managers, usually, use a three-point assessment system here);
• Confidence: demonstrates how much the spent work resources will pay off upon the implementation of a certain feature; this parameter can boost confidence in the priority of concrete features in case if you don’t have any factual data concerning a demand for them (use TA pollings, for instance); if we assess this parameter in numbers, it’d be reasonable to rank it 0-2 points;
• Effort: evaluates how labor-intense certain product requirements are; this is, usually, counted in man hours, man days or man months, depending on the timeframe defined for audience coverage.

Combine these factors to get a proper RICE score:

The result will be directly proportional to the priority of a certain requirement as compared to other requirements.

KANO

This here prioritization model was commonly introduced by Noriaki Kano – a Japanese that contradicted a thesis implying that the more product requirements are fulfilled, the more positively it’ll be perceived by the target audience. In turn, everything’s a bit more complex and one can use the following identifiers to be more in-depth in this aspect:

• must-be: describes a requirement essential to the end product’s performance;
• one-dimensional: an unnecessary requirement, without which, however, client expectations may not be fulfilled;
• attractive: such requirements will additionally satisfy clients (or as much as amaze them); if you don’t implement them, clients may still be glad about the existing functionality; 
• indifferent: such requirements don’t influence the level of client satisfaction;
• reversive: and these requirements can cause negative client impression (being irritating and such).

Walking Skeleton

This one’s a relatively new method introduced at the beginning of the 2000s. It helps to define how important certain features are in terms of deciding on the most proper functionality for your MVP. 

Source: Axisbits – MVP Startup Development

Notice that a set of features defined with the help of this technique can be much smaller as opposed to a number of features an end version of an MVP should have.

So, what the Walking Skeleton method implies? 

Initially, tasks that will provide assets for a minimum set of end-to-end functionality traits and make it possible to release the first working version of the product. Such tasks should be of prime importance. Next, the rest of the tasks are prioritized by groups in a way so that an end product delivers user-satisfying results (here, you can beneficially employ existing user stories pointing out which features users usually enjoy and demand the most). 

Each group of requirements can define a sprint on adding some part of new functionality to the product. It’s very important to keep in mind that working with the Walking Skeleton method, you don’t implement the end architecture in the first functioning incarnation of the product. Architecture and functional tasks are polished and finished in a parallel order in further iterations.

Validated Learning

According to this method, the highest priority should go for the requirements with the highest market risks (i.e., they weren’t checked to be efficient in the market by competitors yet, so it’s unknown how a certain market segment will react to them).

In such a manner, the theory of this method says that the riskiest, unexplored tasks should always go first. Only after you get some feedback on them, should you get to implementing lower-priority requirements.

As a rule, the Validated Learning implementation includes the following steps:

• choose user stories with the biggest risk/least market determination;
• set the success criteria for selected requirements;
• the highest-priority requirements are implemented during the initial iterations;
• analyze factual success criteria;
• conduct a new iteration based on the extracted data and repeat the procedure until the full-on product release.

Conclusion

We hope that we helped you figure out your priorities in efforts to meet the product requirements as closely as possible. Surely, we highlighted only the most commonplace and truly efficient techniques, there are more of those out there still. Perhaps, you have experience with some other techniques or with some methods described in our brief article? Share your thoughts in the comments!

At Axisbits, we are ready to help you implement a project with the workflow based on any prioritization method that will suit your business, be it one of the mentioned or a custom model.