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
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:
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:
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:
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:
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, by 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.
The Hierarchical MoSCoW technique also has its own wiki page.
See the Prioritization wiki page for a discussion of why to prioritize.
This assumes you have evaluated your prioritization needs and decided that Category Assignment Prioritization is the technique you will use.
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.
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.
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.
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.
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?
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.
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.).
As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.
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.
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.
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.
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:
High,
Medium, and
Lowmean. Achieving group consensus on definitions and criteria can be challenging.