Category Assignment Prioritization

IMPORTANT! If you are going to use any prioritization method, be sure that you actually implement more than just the highest level of priority items. If stakeholders consistently see that all that will implemented are the highest priority items, then soon they will stop believing that priority levels mean anything and that everything that is not flagged as the highest priority will not get implemented. And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process.


Also known as: Numeral Assignment Prioritization; Grouping

What is it?

Category Assignment Prioritization is a nominal scale prioritization technique in which the items being prioritized (requirements, objectives, goals, stakeholders, features, functions, etc.) are categorized into groups which have pre-defined levels of importance, based upon pre-defined criteria. It is sometimes also referred to as Numeral Assignment Technique. Sometimes said to be the most common prioritization technique used[1], there are a number of minor variants, of which High-Medium-Low categorizations are the most commonly used.

As a nominal-scale prioritization technique, there are a few important factors to consider when using Category Assignment Prioritization. They are:

  1. Because the result is assignment to a prioritized category, it is impossible to say if any one prioritized item is more or less important than any other item within the same category.
  2. Prioritization occurs within a single context only. There is only a single “prioritization in regards to what?” question being asked. The most common criteria is “to meet the success criteria in the project charter or business case”, but those are often not detailed enough as there can be many divergent (and sometimes conflicting) success criteria.
  3. Almost all prioritization efforts have a time-frame context (the priority assigned is based on the assumption of delivery within a specific time frame). This may be explicitly stated or not, but should always be identified and understood where possible.

The actual categories used for prioritization can be anything you like, as long their relative priority and the criteria for assigning an item to any particular category are well-defined. However, some common variants are included below for your reference.




High, Medium, and Low are probably the most common categories used with Category Assignment Prioritization. This is especially true when prioritization is done in an urgency context (what must be done first). The most common issue with High-Medium-Low is defining EXACTLY what each category means in such a way as to have agreement from all stakeholders in the prioritization process. The definitions below come from a Karl Wiegers article[2] which seems to be the only attempt I have found so far to specifically define what High-Medium-Low mean from a requirements priority perspective:

  • HIGH – A mission critical requirement; required for the next release
  • MEDIUM – Supports necessary system operations; required eventually but could wait until a later release if necessary
  • LOW – A functional or quality enhancement; would be nice to have someday if resources permit


Numeral Assignment

Numeral Assignment is the process of assigning items to a category with a numerical value instead of a name. It is probably the 2nd most commonly used Category Assignment variants. Category labels of 1 to 3 or 1 to 5 are probably the most common.

The main drawback of using numbers is that it is easy to misunderstand the importance of the numbers. Is an item assigned to category 1 part of the most important group because 1 is “first in importance” or is it in the lowest priority category because 1 is “the lowest number”.

An example of the criteria for a 1 to 5 ranking is provided by Marjaie and Kulkarni[4] and assigns 5 as the highest priority. The example high-level criteria for each category were:

  1. Does Not Matter (the customer does not need it)
  2. Not Important (the customer would accept its absence)
  3. Rather Important (the customer would appreciate it)
  4. Very Important (the customer does not want to be without it)
  5. Mandatory (the customer cannot do without it)



The Essential-Conditional-Optional categories come from the same Karl Wiegers article[2] referenced above in the High-Medium-Low section. The article is specific to requirements prioritization, but the scale is one that I think could be used broadly. The definitions for each category he provides are:

  • ESSENTIAL: the product is not acceptable unless these requirements are satisfied
  • CONDITIONAL: these requirements would enhance the product, but the product is not unacceptable if absent
  • OPTIONAL:   these requirements are for things (functions, features, etc.) that may or may not be worthwhile


Top-Ten Selection

In the Top-Ten Selection variant, each participant in the prioritization process selects their top 10 items from the entire pool of items to be prioritized, without assigning any particular order to the items they selected.[3]  In other words, they select 10 items, but don’t say which is #1, #2, #3, etc.  The result is basically a two-category requirements process, those items in the participants Top 10, and those items that are not.  The prioritization team then goes through each participants selections and identifies common items of “Top” priority, from which a target set is agreed upon.  Ideally, each participant will have at least one of the Top 10 items met.

The reason to avoid specific prioritization of the items is help prevent arguments in which each stakeholder wants their #1 priority filled.  Rather, but selecting a group of 10 (or whatever number you choose), each participant knows that they are selecting an un-ordered “set” from which a solution set will be chosen based on commonality of selection (how many times item A was selected), by dependencies (if known), and by resources.

This variant is particularly useful when working on a time-boxed or iterative delivery method.  Or in product management situations where features are selected for upcoming enhancements.  It is much less effective when trying to delivery bespoke software within a highly-specific business problem context.



The MoSCoW Prioritization technique, which is a variant of Category Assignment Prioritization, has its own wiki page.


Hierarchical MoSCoW

The Hierarchical MoSCoW technique also has its own wiki page.


Why do it?

See the Prioritization wiki page for a discussion of why to prioritize.


How do I do it?

This assumes you have evaluated your prioritization needs and decided that Category Assignment Prioritization is the technique you will use.


Step 1

Working with all stakeholders involved in the prioritization process, either select a pre-defined variant of this technique (High-Medium-Low, MoSCoW, etc.) or if starting from scratch define as exactly as possible the categories that will be used, the criteria for assignment to a category, and the relative priority of each category (which is highest, next highest, etc.).

This information should be documented and approved by all stakeholders involved in the prioritization process. As a best practice, it is also a good idea to have all stakeholders who will consume the output of the prioritization process to review the criteria as well. The criteria documentation should be included with the prioritized information so that future consumers will understand what criteria where applied for prioritization category assignment.


Step 2

Define the escalation process that will be used if agreement cannot be reached on the appropriate category that an item should be assigned to. This can include any standard conflict resolution process such as voting, sponsor over-ride, or any other mechanism that stakeholders and the project team can agree to. Defining the escalation process ahead of time should help prevent the prioritization process from getting bogged down or stuck on issues where there are conflicting priorities.


Step 3

Define the prioritization context that will be used. Are you prioritizing for one of a sequence of releases? A single major development effort? For highest business value? To greatest efficiency? Is there a specific time-frame that the prioritization is being considered for? Like the assignment criteria in Step 1 above, this should be documented and kept with the prioritized items.


Step 4

Gather the items that will prioritized (your requirements document, your product backlog, etc.).  Each set of items should be of the same level of abstraction.


Step 5

Decide where the prioritization will be recorded and how. Will it be in the requirements document? A notation next to each item in a product backlog? A physical spot on a whiteboard? Will you use letters to designate the priority? Colors? Physical location?


Step 6

With the stakeholder(s) involved, begin the prioritization process by going through the items one-by-one and assigning a prioritization category.  All items should default to the lowest priority category with the stakeholder(s) having to justify why the item should be a higher priority.


Step 7

Challenge all attempts to prioritize at the highest level. Based on the criteria defined in Step 1 above, the stakeholder(s) should be able to articulate why the item should prioritized at this level (for example: there is no manual work-around, the resulting solution would not be legal, etc.).


Step 8

As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.


Step 9

After all items have been prioritized, go back through all items to ensure none have been missed or need to be re-evaluated given issues that arose in later category assignment discussions.


Step 10

If you have dependencies among the prioritized items (and know what those dependencies are), look for conflicts where a dependent item is prioritized higher than the item it is dependent on. If these are found, either the dependent item should be lowered in priority, or the item on which the dependency rests should be raised in priority.


Step 11

Continue to re-evaluate the prioritization assignments as the situation changes. New items being added to the list, changes in the operating environment (such as changes to the project budget, scope, and timeline), and new information (such as different solution options) may all require a prioritization assignment to be changed.


What Should the Results be?

The results of a Category Prioritization exercise would be that all of the necessary items have been assigned to an appropriate prioritization category based on:

  • The categories defined in Step 1
  • By the criteria specified in Step 1
  • Based on the context specified in Step 3
  • In the manner specified in Step 5
  • In the location specified in Step 5



  • Category Assignment Prioritization is among the best techniques when there are a large number of items (50+) to be prioritized.  And is among the few techniques that is viable when there are a very large number of items (100+) to be prioritized.
  • It is often easier for stakeholders to use than other prioritization techniques that may require them to define just how much of a higher priority one item is versus another, with each item being compared to every other item.



  • Ensuring a common understanding of exactly what criteria should be used for assigning an item to a particular category can often be difficult. Stakeholders often have their own internal understanding of what terms like “High”, “Medium”, and “Low” mean. Achieving group consensus on definitions and criteria can be challenging.
  • If there is more than one stakeholder involved in the prioritization process, it can be difficult to achieve a consensus prioritization of there are significantly different needs and goals among those doing the category assignment.



  • If you need ratio or ordinal scale results (see the Prioritization wiki page), you can reduce your item set by using Category Assignment Prioritization to first divide your items into prioritized groups, and then use a technique that delivers ratio or ordinal results on just the items in each group separately (usually just the highest priority category needs this level of detail). This cuts larger item sets down to smaller sets that work better with the more detailed analysis required for those techniques.



  1. Research Paper: A Comparison of Nine Basic Techniques for Requirements Prioritization. By Mikko Vestola. Helsinki University of Technology.
  2. Article: First Things First – Prioritizing Requirements. By Karl Wiegers. Software Development. September 1999.
  3. Book Chapter: Requirements Prioritization. By Patrik Berander and Anneliese Andrews. In Engineering and Managing Software Requirements. Edited by A. Aurum and C. Wohlin. Springer Verlag. 2005.
  4. Research Paper: Recognition of Hidden Factors in Requirements Prioritization Using Factor Analysis. By Seyed Ali Marjaie and Vasundhara Kulkarni. Symbiosis International University. 2010.




© 2014 by David Olson

Leave a Reply

Your email address will not be published. Required fields are marked *