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?
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.
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 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.
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
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.
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”.
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: 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: 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.
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.
Don't forget to leave your comments below.
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 coaches his clients in business analysis practices, process modeling, and lean project management. When he is not working with his clients or delivering workshops for CEG, he lectures at Northeastern University in Boston in his capacity as Clinical Professor.