You are on page 1of 6

BUILDING SKILLS,

Optimizing Performance

Requirements Prioritization Strategies


By: Dr. Martin Schedlbauer
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 dont have to prioritize requirements, as long as you have unlimited time and resources. And that, of course, is what we dont 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 cant this requirement be deferred to the next release? What business risk is being introduced if a particular requirement cannot be implemented right away?

1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011

BUILDING SKILLS,
Optimizing Performance
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.
Categorical Scale high, medium, low critical, important, desirable Linear Numeric Scale range of numeric values 1 10 or 1 100 Non-Linear Numeric Scale Modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 30

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
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011

BUILDING SKILLS,
Optimizing Performance
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 High/Critical Medium/Important Low/Desirable

Semantics A critical requirement without which the product is not acceptable to the stakeholders. A necessary but deferrable requirement which makes the product less usable but still functional. 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

1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011

BUILDING SKILLS,
Optimizing Performance
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 dont 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.

Present requirement to be estimated

estimate
Use experience to provide best estimate anonymously

Discuss estimates as a group with focus on highest and lowest estimates

merge
Reach consensus or average estimates

present

reflect

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.
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011

BUILDING SKILLS,
Optimizing Performance
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? Hell likely say, So that I can send an invoice. Youd 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 cant 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 cant 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 theyd 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
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011

BUILDING SKILLS,
Optimizing Performance
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.

Do you want to learn even more about Requirements Prioritization Strategies? Call 1.800.288.7246 and ask for Corporate Education Groups schedule of upcoming Business Analysis Training Programs.

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. About Corporate Education Group: Corporate Education Group (CEG) is a nationally-known leader in the areas of project management, business analysis, management, leadership, communications and business process management. CEG's programs are offered on an openenrollment basis at a CEG facility, onsite at a client's location, on demand (online self-paced), or in a virtual instructor-led classroom; in addition, all programs are taught by accomplished subject matter experts, practitioners unmatched within their industries. For more information about our programs and delivery options, call 1.800.288.7246 or visit www.CorpEdGroup.com.

1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com

Copyright 2011