Upload
srinivaskumarus
View
224
Download
0
Embed Size (px)
Citation preview
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?
7/29/2019 Requirements Prioritization Whitepaper
http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 2/6
BUILDING SKILLS,Optimizing Performance
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com
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
7/29/2019 Requirements Prioritization Whitepaper
http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 3/6
BUILDING SKILLS,Optimizing Performance
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com
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
7/29/2019 Requirements Prioritization Whitepaper
http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 4/6
BUILDING SKILLS,Optimizing Performance
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com
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
7/29/2019 Requirements Prioritization Whitepaper
http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 5/6
BUILDING SKILLS,Optimizing Performance
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com
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
7/29/2019 Requirements Prioritization Whitepaper
http://slidepdf.com/reader/full/requirements-prioritization-whitepaper 6/6
BUILDING SKILLS,Optimizing Performance
1 Executive Drive, Suite 301 Chelmsford, MA 01824-2558 | Phone: 1.800.288.7246 | www.CorpEdGroup.com
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.