Requirements prioritization is the process of managing the relative importance and urgency of different requirements to cope with the limited resources of projects. Adequate prioritization ensures that the most critical requirements are addressed immediately in case time or budgets run out.

A common objection by stakeholders to requirements prioritization is that all requirements are important. They often say, “Do I really have to prioritize the requirements? All of them are really important to us?” We can respond to this argument with the simple answer, “No, of course not. You don't have to prioritize requirements, as long as you have unlimited time and resources.” And that, of course, is what we don't have on projects: unlimited time and unlimited resources (people, money, etc.). Prioritization is a way of dealing with the economics of projects: how do we allocate limited resources to maximize benefit?

Who Prioritizes?

Prioritization must be done in collaboration with the stakeholders (customer, product owner, project sponsor, and users) as early as possible so that alternatives can be explored. Developers and stakeholders must work together as they often have conflicting views and needs.

Prioritization Guidance

A common trap is to let the stakeholders choose the priorities without any guidance. In those situations, the stakeholders likely tag most requirements as being critical with only a few as being important but less than critical. The analyst must guide the stakeholders through the prioritization process.

The analyst should challenge the customer:

• What are the consequences to the business objectives if this requirement were omitted?
• Is there an existing system or manual process that could compensate?
• Why can't this requirement be deferred to the next release?
• What business risk is being introduced if a particular requirement cannot be implemented right away?

Asking these questions allows the analyst to clarify whether a requirement is truly needed, if it can be deferred until a later release, or if it is really another project.

Prioritization Goals

Prioritization is done for two somewhat distinct purposes:

• Defining scope
• Scheduling implementation

First, we are trying to determine which requirements ought to be part of the project and which ones are outside scope. Second, for the requirements that are deemed to be within scope of the project, we need to determine which ones are more important than others so that their implementation can be done early in the project just in case we run out of time; after all, we would want the more important requirements to be done in case the project is pre-maturely terminated or the projects run out of time.

Priority Scales

Effective prioritization requires the use of a ranking scale or some other ranking scheme. A number of different scales are used in practice to indicate the relative importance of a requirement: categorical scales as well as linear and non-linear numeric scales (see Figure 1). A project team decides on the ranking scheme at the outset of prioritization effort. Initially, a simple categorical scale can be used to triage requirements that are in or out of scope. Then a numeric scale can be applied to further prioritize the requirements that are in scope. Once the requirements are prioritized, the list is ordered and implementation starts with the most important ones.

Figure 1: Requirements Prioritization Scales

Priority Semantics

All stakeholders need to understand what each priority value means. For a numeric scale, a small value means a low priority (reduced necessity and less urgency), while a large value indicates a high priority (necessary and urgent). For categorical scales, a definition of each categorical value needs to be established so that all stakeholders prioritize from the same perspective. The table below summarizes the priority value semantics.

Priority	Semantics
High/Critical	A critical requirement without which the product is not acceptable to the stakeholders.
Medium/Important	A necessary but deferrable requirement which makes the product less usable but still functional.
Low/Desirable	A nice feature to have if there are resources but the product functions well without it.

Figure 2: Requirements Prioritization Semantics

Strategy: Subjective Ranking

Subjective Ranking is a scheduling strategy in which each stakeholder assigns a priority value from a scale. This strategy can often lead to conflicting priorities as all stakeholders’ priority definitions have the same weight.

Subjective ranking can be done through meetings or through an asynchronous medium such as e-mail. Each stakeholder provides his or her subjective opinion as to the importance of each requirement using an agreed upon ranking scale. Ranking is done for all requirement types starting with the higher-level requirements and then working down to the lower-level requirements; so, start with the business requirements first, then go to the user requirements, and then finish up with detailed functional requirements, non-functional requirements, and finally constraints. Finally, average the priority estimates from all of the stakeholders to arrive at a consensus rank for the requirement.

For example, the functional requirement, “Mark all back ordered items in bold,” is not urgent as it does not address some immediate need of the business and may be deferrable as there is not some immutable deadline or regulatory mandate; so, it should be ranked as “low” or “desirable”.

Group Estimation Techniques

Estimates for priorities (as well as other estimates such as time, effort, or risk estimates) can be improved through the use of planning sessions where estimates are elicited from all stakeholders using group estimation techniques. Among the most commonly used group estimation techniques are Planning Poker and Delphi.

The Delphi technique is widely used for estimating time, effort, risk, and priorities. Estimates are initially provided anonymously by a group of experts. Next, the team of experts discusses the estimates and the providers of the highest and lowest estimates have to “defend” their findings. There must be a reason that they are outliers: do they know something that the others don’t know. Information is exchanged in an open forum. Finally, a second set of estimates is provided anonymously. The final estimates are then averaged. It is important that the estimation be done individually and anonymously so that the estimates are not biased.

Figure 3: Group Estimation Process

Strategy: Objective Alignment

Objective Alignment is a scope delineation strategy in which each discovered requirement is aligned with a business requirement or business objective (business goal).

Start the process by defining the business objectives (business requirements) for the project. Then, for each identified lower level requirement, determine if its implementation is necessary to achieve one of the business objectives. If yes, include the requirement in the project scope, otherwise omit it.

For example, on a warehouse management and inventory control system project, the business objective is to reduce order returns by increasing order accuracy. During elicitation the following user requirement has been identified: allow order handlers to print out a pick list; in addition, during elaboration of the requirements the following functional requirement were discovered: mark any backordered items in bold. These requirements will be in scope only if they are both necessary to achieve the business objective of increasing order accuracy. If there are no manual work arounds, then these user and functional requirements are necessary and therefore should be in scope as they directly support the business objective.

Strategy: Five Whys

Five Whys is a scope delineation strategy. For each identified requirement, the analyst asks the stakeholder at least five times why the requirement is necessary. This tends to surface requirements that are “personal” rather than traceable to a business need. Of course, most likely you will uncover whether the requirement is truly needed after just a few “whys”.

For example, a stakeholder states that he needs the system to provide a button on the main screen to send an invoice. You should ask, “Why do you need that button?" He’ll likely say, “So that I can send an invoice”. You’d respond with, “Why do you need to send invoices,” and so forth.

Strategy: Pain Ranking

Pain Ranking is a scope delineation strategy. This technique starts with a brainstorming session (more often a “gripe” session) in which stakeholders express what they dislike about an existing system or some process; for example, they might say that the system is too slow and that they can’t print out customer statements in reverse order.

The identified “gripes” (or pain points) are ranked using multi-voting where each stakeholder is given some number of votes which can be distributed to the pain points that they consider most important to them. This will identify the most significant pain points for an existing system or process.

Later, each identified user or functional requirement must be able to help resolve a “pain point” and the rank of the pain point determines the priority of the requirement; so, a requirement which “scratches a really bad itch” is then included in the scope. If it can’t resolve a pain point, the requirement is out of scope or has very low priority.

Strategy: Limited Votes

Limited Votes is a scheduling strategy that forces reluctant stakeholders to make decisions. Each stakeholder gets a limited number of votes that can be assigned to any of the identified requirements. Multiple votes per requirement are allowed (multi voting). The key is to provide each stakeholder with fewer votes than there are requirements. This forces the stakeholders to make decisions. If some requirement is truly crucial to them, then they can give it more than one vote; of course, that will take a vote away from some other requirement that they’d perhaps like included.

Strategy: Limited Weighted Votes

This strategy is the same as Limited Votes except that the votes of “important stakeholders” have an increased weight or that some stakeholders may get additional votes. This addresses the political need to appease senior level stakeholders, such as a CIO.

Strategy: Time Boxing

This approach is particularly suited to iterative development. The development of a system is divided into relatively short time periods that are of a fixed duration, often two to four weeks. Prior to each iteration, force stakeholders to choose a small set of requirements that will be addressed in the upcoming iteration. Stakeholders naturally tend to pick the most important requirements. There is no need to fully prioritize the requirements catalog. As new requirements are added to the project, this technique seamlessly absorbs them as prioritization is only done at the beginning of each iteration.

Summary

Ranking of requirements is a critical business analysis activity that serves two important purposes: identifying requirements that must be included in the project scope and determining the urgency of implementation of requirements. The business analyst must know a variety of techniques to produce effective prioritization.

About the Author:

Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he is involved in architecting large-scale distributed software systems for many of his clients.