requirements prioritization whitepaper

7/29/2019 Requirements Prioritization Whitepaper

http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 1/6

BUILDING SKILLS,Optimizing Performance

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

Copyright ©2011

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 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?





Copyright ©2011

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 isordered 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

•high, medium, low

•critical, important, desirable

Categorical Scale

•range of numeric values

•1 – 10 or 1 – 100

Linear Numeric Scale

•Modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 30

Non-Linear Numeric Scale





Copyright ©2011

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 valuesemantics.

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





Copyright ©2011

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 estimateshave 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 discoveredrequirement 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.

•Present

requirement to beestimated

present

•Use experience toprovide bestestimateanonymously

estimate•Discuss estimates as

a group with focuson highest andlowest estimates

reflect

•Reach consensus oraverage estimates

merge





Copyright ©2011

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 tosurface 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





Copyright ©2011

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 Group’s 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 open-

enrollment 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.

http://www.corpedgroup.com/

http://www.corpedgroup.com/

requirements prioritization whitepaper

Documents