العرض التقديميpmi Pba

PMI BUSINESS ANALYSIS
EXAM PREPARATION COURSE

14 – 18 Aug 2022
Riyadh - KSA
INDEX
1. PMI-PBA Certification
2. Introduction
3. The Environment in Which Business Analysis is Conducted
4. The Role of Business Analyst
5. Needs Assessment
6. Stakeholder Engagement
7. Elicitation
8. Analysis
9. Traceability & Monitoring
10. Solution Evaluation
PMI-PBA CERTIFICATION
PMI-PBA® CERTIFICATE ELIGIBILITY REQUIREMENTS
Educational Business Analysis Training in Business

General Project Experience
Background Experience Analysis
7,500 hours (5 years) *2,000 hours working on project teams. This
working as a project experience can be inclusive of the 7,500
Secondary degree 35 contact hours.
practitioner of hours of business analysis experience listed.
(High school diploma, Hours must have been
business analysis. Any business analysis experience that occurred
associate’s degree or earned in business
This experience must within the context of a project can be included.
global equivalent). analysis practices.
have been earned in This experience must have been earned in the
the last 8 years. last 8 years.
4,500 hours (3 years) *2,000 hours working on project teams. This
working as a project experience can be inclusive of the 4,500
35 contact hours.
Bachelor’s degree or practitioner of hours of business analysis experience listed.
Hours must have been
higher degree (or business analysis. Any business analysis experience that occurred
earned in business
global equivalent). This experience must within the context of a project can be included.
analysis practices.
have been earned in This experience must have been earned in the
the last 8 years. last 8 years.
PMI-PBA® CERTIFICATION PROCESS
The PMI certification program governs the PMI-PBA® certification process. This robust
process was utilized to develop, and now maintains, the PMI-PBA® certification. It serves
practitioners with different levels of education and experience. Candidates are assessed by
examining their competency using three measures.
Refer to the PMI Professional in Business Analysis (PMI-PBA)® Handbook for full details on
this process.
Reviewing
Education Testing
and Competence
Experience
Ongoing
Development
PMI-PBA® CERTIFICATION PROCESS TIMELINE
Candidates for PMI-PBA® certification must follow a standard

process.
Application Certification
Submission Cycle
(90-days)
Certification
Application Maintenance
Completeness (3 Years)
Review
(5 days)
Certification
Renewal
Applicant
Payment
Certification
Process
Suspension
Audit Process
(1 Year)
(5-7 Days)
Certification
Expiration
Multiple-Choice
Examination
Eligibility
(1 Year)
KEY DOMAINS AND TASKS FOR THE PMI-PBA®
The role delineation study for business analyst was instrumental in

the creation of the PMI-PBA® certification examination.
The tasks identified in the study have been organized into major
domains of practice and are listed in the PMI- PBA® Examination
Content Outline. Each exam question is referenced to texts, such as
those noted on the PMI-PBA® examination preparation reference
list.
Candidates are urged to use the Examination Content Outline to

guide their study and are also encouraged to study current
references in agile, such as those on the reference list.
ABOUT PMI-PBA® EXAM
Scored Questions Unscored Questions Total

175 25 200
Allotted Time: 4 Hours
PMI Member Non-PMI

Member
Exam Price 405$ 555$
ABOUT PMI-PBA® EXAM
Domain Percentage
Needs Assessment 18%
Planning 22%
Analysis 35%
Traceability & Monitoring 15%
Evaluation 10%
Total 100%
INTRODUCTION
COMMON VOCABULARY
Business Analysis
Business Analyst
Product
Requirement (Product Requirement)
Product Information
Solution
Stakeholder
WHAT IS BUSINESS ANALYSIS?
“The set of activities performed to identify business needs; recommend relevant solutions;
and elicit, document, and manage requirements.”
BUSINESS ANALYST
“Any resource who is performing the work of business analysis.”
Regardless of the job title as the term is used in the broad sense and represents all the roles
that are responsible for performing Business Analysis activities across projects, programs or
portfolios
PRODUCT
“An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item.
Additional words for products are materials and goods.”
A product can be tangible or intangible, they provide business value.
REQUIREMENT
“A condition or capability that is required to be present in a product, service, or result to satisfy a contract
or other formally imposed specification.”
Business
Quality Stakeholder
Requirement
Types
Project Solution
Transition
REQUIREMENT TYPES
Business Requirement: “Requirements that describe the higher-level needs of the organization, such as the business issues or opportunities,
and which provide the rationale for why a project is being undertaken.”
Stakeholder Requirement: “A requirement that describes the need of a stakeholder or stakeholder group.”
Solution Requirement: “A requirement that describes the features, functions, and characteristics of a product, service, or result that will
meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.”
Transition Requirement: “Requirements that are the temporary capabilities, such as data conversion and training requirements, needed to
transition from the current as-is state to the future state.”
Project Requirement: “The actions, processes, or other conditions the project needs to meet. These requirements focus on aspects of
project execution.”
Quality Requirement: “A condition or capability that will be used to assess conformance by validating the acceptability of an attribute for
the quality of a result.”
REQUIREMENT TYPES
Project requirements and quality requirements. These requirement types are

not part of the business analysis effort and are not considered to be product
requirements. Project and quality requirements focus on project execution
and are part of the project management effort.
It would be difficult to accurately describe the work needed to deliver the

solution and determine how to validate the successful completion of project
deliverables without some information about the solution. Project and quality
requirements, therefore, cannot be defined until the solution is somewhat
defined.
RELATIONSHIPS AMONG REQUIREMENT TYPES
A single business requirement may be supported by multiple stakeholder and solution
requirements
A single stakeholder requirement may be supported by many solution requirements
Solution requirements may be written as functional or nonfunctional requirements
Because transition requirements describe the transition from the current to future state, they
support the implementation of stakeholder and solution requirements
Project requirements support product requirements, as project requirements describe the
work needed to deliver the unique solution(s)
Quality requirements support project requirements because they are used to validate the
successful completion of a project deliverable or the fulfillment of other project
requirements.
RELATIONSHIPS AMONG REQUIREMENT TYPES
PRODUCT INFORMATION
“All elements needed to produce a solution successfully. Product

information can include one or more of the following: business,
stakeholder, solution or transition requirements, models, assumptions,
dependencies, constraints, issues, and risks.”
Product Information include:

1. Business Goals and Objectives
2. Requirements
3. Analysis Models
4. Backlogs
5. User Stories
6. Acceptance Criteria
7. Etc.
SOLUTION
“Something that is produced to deliver measurable business value to meet

the business need and expectations of stakeholders. It defines what a
specific portfolio component, program, or project will deliver. A solution
could be one or more new products, components of products, or
enhancements or corrections to a product.”
STAKEHOLDER
“An individual, group, or organization who may affect, be affected by, or perceive itself to be
affected by a decision, activity, or outcome of a project, program, or portfolio.”
Stakeholders have different roles and relationships across the business analysis effort. Their
involvement can change over the course of the product life cycle.
Different stakeholders may have competing requirements and expectations that could create
conflicts for decisions about approving solution options, requirements, or allocating
requirements across releases.
PRODUCT AND PROJECT LIFECYCLES
Business analysis focuses on products, whereas project management focuses on delivering
projects to create or evolve products. Both views are essential because the concepts of
products and projects are highly intertwined
A product life cycle is a series of phases that represent the evolution of a product from
concept through delivery, growth, maturity, maintenance, and retirement. A product lifecycle
may consist of multiple project lifecycles
Business analysis focuses on the entire product life cycle, including the many projects that
advance the product.
PRODUCT AND PROJECT LIFECYCLES
A project life cycle is the series of phases through which a project passes from its initiation to
its closure. The phases can be sequential or they may overlap.
BUSINESS ANALYSIS PROCESS GROUPS
Defining and Aligning Process Group. The processes performed to investigate and evaluate
the viability for initiating a new product or changes to or retirement of an existing product
Initiating Process Group. The process performed to define the portfolio, program, or project
objectives and apply resources to a portfolio component, program, project, or project phase.
Planning Process Group. The processes performed to determine an optimal approach for
performing business analysis activities
Executing Process Group. The processes performed to elicit, analyze, model, define, verify,
validate, prioritize, and approve all types of product information
Monitoring and Controlling Process Group. The processes performed on an ongoing basis to
assess the impact of proposed product changes within a portfolio, program, or project to
assess business analysis performance and to promote ongoing communication and
engagement with stakeholders.
Releasing Process Group. The process performed to determine whether all or part of a
solution should be released and to obtain acceptance that all or part of a solution is ready to
be transitioned to an operational team that will take ongoing responsibility for it.
BUSINESS ANALYSIS KNOWLEDGE AREAS
Needs Assessment. Analyzing current business problems or opportunities to

understand what is necessary to attain the desired future state.
Stakeholder Engagement. Identifying and analyzing those who have an interest in
the outcome of the solution to determine how to collaborate and communicate with
them.
Elicitation. Planning and preparing for elicitation, conducting elicitation, and
confirming elicitation results to obtain information from sources.
Analysis. Examining, breaking down, synthesizing, and clarifying information to further
understand it, complete it, and improve it.
Traceability and Monitoring. Tracing, approving, and assessing changes to product
information to manage it throughout the business analysis effort.
Solution Evaluation. Validating a full solution or a segment of a solution that is about
to be or has already been implemented to determine how well a solution meets the
business needs and delivers value to the organization.
RELATIONSHIPS ACROSS KNOWLEDGE AREAS
BUSINESS ANALYSIS TAILORING
Tailoring involves selecting the appropriate business analysis processes, tools, techniques,
inputs, and outputs for use on a specific portfolio, program, or project. The business analyst
performs this selection activity in collaboration with the project manager, sponsor, functional
managers, other business analysts, or some combination thereof.
BUSINESS ANALYSIS TAILORING
Factors that impact Business Analysis tailoring:

Chosen Project Lifecycle
Stakeholder knowledge and experience
Location of project and participants
Business Analysis experience on the team
Maturity level of the organization
Corporate culture
Importance of Project and its components
Stakeholders’ Risk Apetite
Team Stability
Project Size and Complexity
Standards and Regulations
Vendor Involvement
PROJECT & DEVELOPMENT LIFECYCLE
Project life cycles can be predictive or adaptive. Within a project life cycle, there are generally one or more phases that are associated with the development of the
product, service, or result. These are called a development life cycle.
Development life cycles can be :
oPredictive, the project scope, time, and cost are determined in the early phases of the life cycle. Any changes to the scope are carefully managed. May also be referred
to as waterfall life cycles.
oIterative, the project scope is generally determined early in the project life cycle, but time and cost estimates are routinely modified as the project team’s
understanding of the product increases. Iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the
product.
oIncremental, the deliverable is produced through a series of iterations that successively add functionality within a predetermined time frame. The deliverable contains
the necessary and sufficient capability to be considered complete only after the final iteration.
oAdaptive life cycles are agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration. May also referred to as agile or
change-driven life cycles.
oHybrid life cycle is a combination of a predictive and an adaptive life cycle. Those elements of the project that are well known or have fixed requirements follow a
predictive development life cycle, and those elements that are still evolving follow an adaptive development life cycle.
WATERFALL APPROACH (PREDICTIVE)
BA Plan for
Requirements Baseline
Identify Requirements
Stakeholders
Define Analyze
• Analyze • Elicit, Model,
Design Build Test Deploy
Problem, Document &
Understand Review
Business & Requirement
Project Manage &
s Communicate
Background
Requirements
AGILE (ADAPTIVE)
A Scrum Framework
THE ENVIRONMENT IN
WHICH BUSINESS ANALYSIS
IS CONDUCTED
MAJOR INFLUENCES
ENTERPRISE ENVIRONMENTAL FACTORS
Conditions not under the immediate control of the team that influence, constrain, or direct
the portfolio, program, or project. In business analysis, these conditions influence, constrain,
or direct how business analysis is conducted and are not under the control of business
analysts. Any given EEF can be external or internal to an organization.
External to The Organization:
Marketplace Conditions
Social Culture
Stakeholders Expectations
Legal and Contractual Restrictions
External Professional Standards for Business Analysis
Internal to The Organization:
Organizational culture, structure, and governance.
Market research and experimentation.
Architecture and infrastructure.
Information technology software..
Interest and level of commitment to reuse the results of business analysis.
Human resources management policies and procedures.
Resource policies, procedures, and availability.
Employee capability.
Security policies, procedures, and protocols.
ORGANIZATIONAL PROCESS ASSETS
Organizational process assets (OPAs). The plans, processes, policies, procedures, and
knowledge bases specific to and used by a performing organization.
Generally, business analysis processes, policies, procedures, and templates are not updated
as part of the project work in support of creating or modifying a product. Updates are
usually established by a global organizational function, such as a business analysis center of
excellence, business analysis community of practice, business analysis shared service
organization, or possibly a project management office (PMO).
Processes, Policies and Procedures
Guidelines and criteria.
Specific organizational standards.
Project life cycles.
Templates.
Change control procedures for product requirements and other product information.
Requirements management tool procedures.
Financial controls procedures.
Issue and defect management procedures
Organizational communication requirements as applied to business analysis processes.
Procedures.
Risk management templates.
Standardized guidelines.
Project closure guidelines or requirements.
Corporate Knowledge Base
Business knowledge repositories.
Configuration management knowledge repositories.
Historical information and lessons learned knowledge repositories.
Issue and defect management data repositories.
Data repositories for metrics.
THE ROLE OF BUSINESS
ANALYST
BUSINESS ANALYST’S SPHERE OF INFLUENCE
Business analysts may lead, but they do not oversee project resources; this is the work of the
project manager.
A lead business analyst may oversee the work of less experienced business analysts on the
team, or a manager of business analysis may be responsible for managing a pool of business
analyst resources from an assignment or allocation perspective.
At the project level, it is the project manager who is responsible for resource allocation,
scheduling, and work progress, including that of business analysts.
BUSINESS ANALYST’S SPHERE OF INFLUENCE
Business analysts do manage stakeholder engagement, which is often considered an area of
overlap with project managers. Looking more closely, business analysts have different
objectives from project managers; therefore, each role manages engagement with
stakeholders for different purposes.
BUSINESS ANALYST’S SPHERE OF
INFLUENCE
NEEDS ASSESSMENT
NEEDS ASSESSMENT OVERVIEW
4.1 Identify Problem or Opportunity
4.2 Assess Current State
4.3 Determine Future State
4.4 Determine Viable Options and Provide Recommendation
4.5 Facilitate Product Roadmap
4.6 Assemble Business Case
4.7 Support Charter Development
4.1 IDENTIFY PROBLEM OR OPPORTUNITY
Inputs Tools & Techniques Outputs
1. Assessment of business value 1. Benchmarking 1. Business need

2. Elicitation results 2. Competitive analysis 2. Situation statement
(unconfirmed/confirmed) 3. Document analysis
3. Enterprise environmental 4. Interviews
factors 5. Market analysis
6. Prototyping
To avoid focusing on the solution too soon, emphasis is placed on understanding the current environment and
analyzing the information uncovered.
Various types of elicitation are performed to draw out sufficient information to fully identify the problem or
opportunity. Once there is a broad understanding of the situation, it is necessary to elicit relevant information to
understand the magnitude of the problem or opportunity
INPUTS
Assessment of Business Value: refers to the time, money, goods, or intangibles in return for something exchanged.
Business analysis involves reviewing implemented or partially implemented solutions to assess whether the business value that the
organization expected to provide is being delivered
Elicitation Results (Unconfirmed/Confirmed): consist of the business analysis information obtained from elicitation activities. Results of
prior discussions can take many forms, such as sketches, diagrams, models, and notes on flipcharts, sticky notes, or index cards.
Through analysis and continued collaboration, the elicitation results used to identify the problem or opportunity may transition from
unconfirmed to confirmed, demonstrating the iterative nature of elicitation and analysis within business analysis.
Enterprise Environmental Factors (EEFs)

TOOLS AND TECHNIQUES
Benchmarking: is a comparison of an organization’s practices, processes, and measurements of results against established standards or
against what is achieved by a “best in class” organization within its industry or across industries.
When data cannot be feasibly collected or insufficient information exists within an organization to understand a current state, benchmarking
results may be used to provide information
Competitive Analysis: a technique for obtaining and analyzing information about an organization’s external environment. Results of
competitive analysis may identify competitor strengths that impose threats or may uncover an area of weakness an organization has in
comparison to its competition
Discoveries may identify gaps where customer needs are not being met or are being completely overlooked, providing an opportunity to
develop products to address the void or identify new markets for existing products.
Document Analysis: elicitation technique used to analyze existing documentation to identify information relevant to the requirements.
Interviews: formal or informal approach to elicit information from individuals or groups of stakeholders by asking questions and
documenting the responses provided by the interviewees
Market Analysis: a technique used to obtain and analyze market characteristics and conditions for the organization’s market area and then
overlay this information with the organization’s plans and projections for growth
Market analysis results can be used to support strategic planning initiatives and provide context for future elicitation
Prototyping: method of obtaining early feedback on requirements by providing a model of the expected solution before building it.
When identifying problems or opportunities, this technique is useful to learn and discover what is valuable from the perspective of the
customer.
OUTPUTS
Business Need: the impetus for a change in an organization, based on an existing problem or
opportunity.
It provides the rationale for why organizational changes are being proposed and why a new portfolio
component, program, or project is being considered.
Situation Statement: an objective statement of a problem or opportunity that includes the statement
itself, the situation’s effect on the organization, and the resulting impact.
Situation Statement Example:
“The cost for processing claims has been rising steadily, increasing at an average rate of 7% per year, over the last 3
years. The existing method for submitting claims either by phone or the Internet involves significant processing delays
and has resulted in the need to increase staffing to process the calls and personally investigate the claims.”
ADAPTIVE VS. PREDICTIVE
Aspects to be
Adaptive Predictive
Tailored
Name Identify Problem or Opportunity
Performed prior to portfolio, program, or project
Performed prior to portfolio, program, or project
initiation during an early planning iteration; the
initiation, Needs Assessment is performed as a more
Approach degree to which Needs Assessment is formally
formal process where the situation statement is
performed depends upon organizational, cultural,
drafted, reviewed, and approved.
environmental, market, and/or regulatory constraints.
Adaptive projects often create a brief statement of project intent.
In whatever format it takes, the statement of intent typically
states the business objectives, value propositions, benefits, goals,
milestones, customers and partners, etc., that were
identified as part of a strategic planning effort and
are part of the project. It may also include very Documented situation statement. Any models needed
Deliverables high-level user epics that are later broken down into to assess the situation.
user stories when the story is selected as a feature of
a release.
Situations involving higher risk or in regulated
industries may require a documented situation
statement.
4.2 ASSESS CURRENT STATE
1. Enterprise and business 1. Business architecture 1. Current state assessment

architectures techniques
2. Organizational goals and 2. Business capability analysis
objectives 3. Capability framework
3. Situation statement 4. Capability table
5. Elicitation techniques
6. Glossary
7. Pareto diagrams
8. Process flows
9. Root cause and opportunity
analysis
10. SWOT analysis
INPUTS
Enterprise and Business Architecture: collection of business and technology components needed to operate an enterprise
Enterprise architecture is assembled in the form of a schematic or model. Models can be analyzed to understand the strategic and
operational impacts that a change will have on various aspects of the enterprise.
Organizational Goals and Objectives: Goals define the measurable targets that a business establishes in order to deliver on its strategy.
Objectives are the statements aimed at directing the actions of the organization to reach its goals.
Situation Statement
Business Architecture Techniques: organizational frameworks available to model business architecture, each providing different approaches
for analyzing various aspects of the business
These models can serve as checklists, frameworks, or job aids for assessing the current state and can be used to guide strategy decisions
within the organization, specifically at the portfolio and program levels.
Business Capability Analysis: a technique used to analyze performance in terms of processes, people skills, and other resources used by an
organization to perform its work.
In the current state, the objective is to determine a specification by which business capabilities can be assessed and performance measured
and monitored on an ongoing basis. In the future state, this specification can be used to establish a benchmark for future performance.
Capability Framework: a set of descriptions about the key skills, knowledge, behaviors, abilities, systems, and overall competencies of value
to an organization.
Some organizations refer to these types of frameworks as maturity models.
Capability Framework Sample

Capability Table: used for analyzing capabilities in a current or future state. Within future-state analysis, the model can be used to display
the capabilities needed to solve a problem or seize an opportunity.
The technique can be applied to depict the relationship between a situation, its root causes, and the capabilities needed to address the
situation.
Elicitation Techniques: used to draw information from various sources
Document analysis.
Interviews.
Observation. provides a direct way of eliciting information about how a process is performed or a product is used, by viewing individuals in their own
environment performing their jobs or tasks and performing processes. Through observation, the observer can experience the current state firsthand.
Questionnaires and surveys. Written sets of questions designed to quickly accumulate information from a large number of respondents. Surveys can be
developed to elicit information about the current state
Glossary: a list of definitions for terms and acronyms about a product.
A glossary should be started as early as possible in portfolio, program, or project analysis to support common language; therefore, it is a
technique that is commonly started with needs assessment activities.
Pareto Diagrams: a histogram that can be used to communicate the results of root cause analysis.
The data results are displayed in descending order, which easily draws attention to the problems, causes, or costs that have the greatest
significance and thereby require the most attention. The format of a Pareto diagram helps demonstrate the 80/20 principle whereby 80% of
problems can be related back to 20% of the causes
Pareto Diagram Sample

Process Flows: describe business processes and the ways stakeholders interact with those processes.
It can be used to document current as-is processes of the business. It can also be used to analyze the ways in which a process contributes to
a given problem. Value stream maps—a variation of process flows—can be used to identify process steps that add value (value stream) and
those that do not add value (waste).
Root Cause and Opportunity Analysis
Root cause analysis. Techniques used to determine the basic underlying reason for a variance, defect, or risk. When applied to business problems, root cause
analysis can be used to discover the underlying causes of a problem so that solutions can be devised to reduce or eliminate them.
Opportunity analysis. Techniques used to study the major facets of a potential opportunity to determine the possible changes in products offered to enable
its achievement. Opportunity analysis may require additional work to study the potential markets an organization may consider entering.
Main techniques for root cause and opportunity analysis are Cause-and-Effect Diagrams and Five-Whys
Five-Whys: A technique that suggests anyone trying to understand a problem needs to ask why it is
occurring up to five times in order to thoroughly understand the problem’s causes
Cause-and-Effect Diagrams:
Fishbone Diagram. used to depict a problem and its root causes in a visual manner
Interrelationship Diagram. diagram that depicts related causes and effects for a given situation
SWOT Analysis: a technique for analyzing the strengths

(S) and weaknesses (W) of an organization, project, or
option, and the opportunities (O) and threats (T) that
exist externally.
OUTPUTS
Current State Assessment: an understanding of the current mode of operations, or the as-is state of the organization. It is a culmination of
the analysis results obtained from examination of the existing organizational environment. Typical information captured during the analysis of
the current state might be a high-level overview of the existing business context.
Aspects to be
Adaptive Predictive
Tailored
Not necessarily a formally named process;
Name Assess Current State (or as-is analysis)
performed as part of initial planning or iteration 0
As-is analysis can be performed throughout the
As-is analysis is performed up front as a starting
project, as each iteration may focus the as-is
point to provide context for future business
discussion on a slice of the overall context. The
analysis work. If a recent current state
Approach as-is environment will continue to change, and
assessment is available, it may be possible to
therefore, will need to be continually assessed to
leverage historical information and avoid
understand how changes in the current state
conducting another current state assessment.
might impact proposed work within the backlog.
As-is models may be completed to a detailed
Just enough modeling in order to move forward
level. Models constructed may cover the entire
on discussions regarding the future state. The
problem space up front before requirements
scope of analysis and, hence, the deliverables
elicitation begins. May include models produced
Deliverables are focused on the context necessary for the
in a process modeling tool. The information
early iterations of development work or to
assembled from the current state assessment
provide context when developing a lightweight
may be packaged into a current state assessment
business case.
document leveraging a standardized template.
4.3 DETERMINE FUTURE STATE
1. Business need 1. Affinity diagram 1. Business goals and objectives

2. Current state assessment 2. Benchmarking 2. Required capabilities and
3. Enterprise and business 3. Capability table features
architectures 4. Elicitation techniques
4. Situation statement 5. Feature model
6. Gap analysis
7. Kano analysis
8. Process flows
9. Purpose alignment model
10. Solution capability matrix
The team develops a clear definition of what the future state will look like, including identification of the capabilities and
features required to enable the organization to transform from its current as-is state into this proposed to-be future. The
required capabilities and features described here identify what is needed, but do not prescribe a recommended solution.
Further analysis is required to evaluate how the capabilities and features will be delivered
INPUTS
Business Need
Current State Assessment
Enterprise and Business Architectures
Situation Statement
They all provide context in understanding the problem or opportunity along with current capabilities that might need enhancement for the
future state.
Affinity Diagram: display categories and subcategories of ideas that cluster or have an affinity to one another.
When defining future state considerations, affinity diagrams are used to process a large set of information or ideas into a manageable set of
data organized by categories
Benchmarking; Benchmarking studies often guide final recommendations to address the situation as well as highlight which
recommendations not to pursue
Capability Table; This technique is a good choice for a model to relate the information obtained during the current state analysis with the
information resulting from the future state discussions
Elicitation Techniques:
Brainstorming: Used to identify a list of ideas within a short period of time
Facilitated Workshops: Structured meetings led by a skilled, neutral facilitator and a carefully selected group of stakeholders to collaborate and work toward
a stated objective.
Feature Model: visual representation of all the features of a solution arranged in a tree or hierarchical structure.
The strength of the model is its ability to help visually and logically group feature sets.
Feature Model Sample

Gap Analysis: a technique for comparing two entities, usually the as-is and to-be state of a business.
During Needs Assessment, gap analysis is performed by examining the differences between the current
and future states.
Gap analysis is performed by comparing the required capabilities against the existing capabilities and
identifying the difference, or “gap.” This gap refers to the missing capabilities that the organization
needs to acquire to address the business need in the future state
Kano Analysis: a technique used to model and analyze product features by considering the features
from the viewpoint of the customer
There are five product feature categories commonly used in a Kano model:
Basic. Features that provide little satisfaction to stakeholders, but, when missing from the end solution, cause
extreme dissatisfaction.
Performance. Features that stakeholders think about, desire, and use to consciously evaluate the final solution.
Delighters. Features that differentiate the product from competitors’ products and are sometimes referred to as the
“wow” factor.
Indifferent. Features that neither satisfy nor dissatisfy a customer.
Reverse. Features that decrease a stakeholder’s satisfaction level when present and increase it when excluded from
the final product.
Kano Model Sample

Process Flows; a good technique for performing what-if analysis to walk through various future state
scenarios with key stakeholders
Purpose Alignment Model: a technique that provides a framework to support strategic or product
decision
making.
The framework is used to categorize options by aligning them with the business purpose they support,
used as a basis for making strategic or high-level product decisions, some organizations also use it to
analyze and facilitate discussions about product requirements and features, including the value each
provides.
Differentiating. Features in this category are mission critical and provide high market differentiation. They can help
the organization gain market share, improve its competitive advantage, and outrival its competitors.
Parity. Features here help the organization maintain its parity in the marketplace. Investments in parity features may
be mission critical, but they do not provide the organization with a competitive advantage.
Partner. Features assigned here are not considered mission critical, but if provided, they would enable the
organization to differentiate itself in the market.
Who cares. Features in this category are neither differentiating nor mission critical to the organization. Features that
end up in this category are generally not built.
Purpose Alignment Sample

Solution Capability Matrix: a model that provides a simple visual way to examine capabilities and
solution components in one view, identifying where capabilities will be addressed in the new solution.
When timing information is added, the product team can use the model during planning discussions to understand
when different solution components are expected to be delivered.
The Xs may be replaced with a version number or an iteration number if the team wishes to
communicate when a capability will be addressed in the solution
OUTPUTS
Business Goals and Objectives: identify what the business expects the portfolio, program, or project to
deliver. Business goals and objectives align to the organizational goals and objectives, but are at a lower
level because they specify stated targets that the business is seeking to achieve.
Required Capabilities and Features: the list of net changes the organization needs to obtain in order
to achieve the desired future state. The capabilities and features listed do not prescribe a solution.
Additional analysis is still needed to determine how these capabilities and features will be delivered.
Aspects to be
Adaptive Predictive
Tailored
Not a formally named process and performed as
Name part of backlog refinement, business modeling, Determine Future State
initial planning, or iteration 0
Teams explore the future state in slices and discuss it in terms of
To-be analysis is performed up front prior to
themes, goals, and objectives. Some organizations may take a
initiating a project to understand the business
broader or organizational viewpoint to this work. Typically, some
goals and objectives. Results from gap analysis
high-level information on the future state is formed at either
are understood to define required capabilities.
project initiation or as part of iteration 0, but that information is
Approach constantly
The to-be state is fully defined and understood
before moving forward on proposing viable
evolving as new information emerges. Future state
solution approaches. The future state definition is
information is reviewed prior to each iteration to
formally documented, reviewed, and approved
ensure that the capabilities required for the future
with the business.
state are known and understood.
The future state definition may be represented in
lightweight documentation. Models utilized to
A future state definition can be documented
facilitate discussions involve a low level of
within a tool or within a formal document such as
formality and are often developed on whiteboards
Deliverables or flipcharts. The future state definition is captured
a business case. Models built to assist in defining
the future state are often formalized, created with
and made available to the team on an ongoing
a modeling tool, and archived for future reference.
basis. Other deliverables may include roadmaps,
story maps, and product backlog.
4.4 DETERMINE VIABLE OPTIONS AND PROVIDE
RECOMMENDATION
1. Business goals and objectives 1. Benchmarking 1. Feasibility study results

2. Enterprise and business 2. Cost-benefit analysis 2. Recommended solution option
architectures 3. Elicitation techniques
3. Required capabilities and 4. Feature injection
features 5. Group decision-making
4. Situation statement techniques
6. Real options
7. Valuation techniques
8. Weighted ranking
The product team considers the information from the current and future state analysis when formulating these options.
The product team also determines the solution approach for each option. The solution approach is a high-level definition
about the considerations and steps necessary to deliver the solution and thereby transition the business from the current to
the future state.
4.4 DETERMINE VIABLE OPTIONS AND PROVIDE
RECOMMENDATION
Determining Viable Options and providing a recommendation entail the following activities:
1. Identifying viable options
2. Conducting feasibility analysis
• Assumptions and Constraints
• Dependencies
• Product Risks
• Culture
• Operational feasibility
• Technological feasibility
• Supportability
• Cost-Effectiveness feasibility
• Time feasibility
• Value
• Validation
3. Defining preliminary product scope
4. Defining high-level transition requirements
5. Recommending the most viable option
INPUTS
Business Goals and Objectives; Each of the viable options under consideration will be assessed to
determine how well it satisfies the stated business goals and objectives
Enterprise and Business Architectures; When presenting viable options, each option can be analyzed
and explained within the context of existing architectures. Doing this helps frame up the size and
complexity of each option in terms that decision makers can more easily relate to and understand.
Required Capabilities and Features; Each proposed option will address the capabilities and features
differently
Situation Statement; provides context for discussions when identifying a list of viable options.
Benchmarking; can help stimulate ideas for formulating a list of viable options
Cost-Benefit Analysis: a financial analysis tool used to compare the benefits provided by a portfolio component, program, or project against
its costs
It is commonly used to identify the most viable option from a set of options, often conducted prior to project initiation, as part of portfolio or
program management activities.
Elicitation Techniques; Prototypes help eliminate uncertainties about options, thereby reducing product-related risks.
Feature Injection: framework and set of principles used to deliver successful outcomes by improving and expediting how a product team
develops and analyzes product requirements.
It guides the team to analyze only those features that are deemed to be of the highest value.
Group Decision-Making Techniques: techniques that can be used in a group setting to bring participants to a final decision on an issue or
topic under discussion.
Includes: Autocratic, Delphi, Force Field Analysis, Majority, Plurality, Unanimity
Real Options: a decision-making thought process that can be used on projects that follow an adaptive
delivery model.
Two fundamental principles are applied to decision making with real options. The first is to reduce the
number of decisions that need to be made in the short term, and the second is to delay all decision
making until as late as possible.
Valuation Techniques: techniques that quantify the return or value that an option will provide.
Valuation techniques are utilized when conducting a cost-benefit analysis to establish criteria for
objectively assessing a solution.
Techniques included:
Internal rate of return (IRR). The projected annual yield of an investment, incorporating both initial and ongoing
costs.
Net present value (NPV). The future value of expected benefits expressed in the value that those benefits have at
the time of investment.
Payback period (PBP). The time needed to recover an investment, usually in months or years. The longer the PBP,
the greater the risk.
Return on investment (ROI). The percentage return on an initial investment. ROI is calculated by taking the total
projected net benefits and dividing them by the cost of the investment.
Weighted Ranking: a technique used to support objective decision making. It is typically performed
with the use of a weighted ranking matrix.
OUTPUTS
Feasibility Study Results: the summarized outcomes obtained from the completion of the feasibility
analysis.
Recommended Solution Option: the solution choice determined to be the best course of action for
addressing the business need.
The recommended solution option should include a summary of why the option was chosen, along with a high-level
description of the process utilized to reach the decision. If any subjective criteria were applied in the decision-making
process, these, too, should be included.
At the portfolio or program level, analysis results are reviewed and a decision and recommendation is reached, which
consists of the best course of action for the portfolio or program. At the project level, the recommended solution is a
high-level description of the product(s) to be developed.
Aspects to be
Adaptive Predictive
Tailored
Determine Viable Options and Provide
Not a formally named process; performed as part Recommendation, business case analysis,
Name
of iteration 0 or later iterations or
feasibility study
Viable options are identified, feasibility studies
High-level vision of the solution and an early completed, and a recommended solution is
version of product scope might be created. Initial selected prior to portfolio, program, or project
Approach solution options are evaluated during iteration 0. initiation. Project and product scope are
Tasks can be created as “spikes” to investigate the determined and agreed to up front, and
feasibility of a solution during an iteration. adherence to both are managed throughout the
course of the program or project.
Solution options are rarely documented and
instead just implemented in the final product.
Feasibility study results and recommended
Deliverables Functional or technical spikes might be performed
solution option.
to research or investigate viable options for
implementing user stories.
4.5 FACILITATE PRODUCT ROADMAP DEVELOPMENT
1. Business goals and objectives 1. Facilitated workshops 1. Product roadmap

2. Required capabilities and 2. Feature model
features 3. Product visioning
4. Story mapping
The process of developing a product roadmap is a collaborative effort and brings together resources from the business and
development team to form a shared understanding of what is being requested and why. The process can also entail the
development of different “what if” scenarios used by the team in reviewing various planning and delivery options and in
making and solidifying their final decisions.
INPUTS
Business Goals and Objectives; to align the product with the stated business goals and objectives.
Required Capabilities and Features; Required capabilities and features can be reflected in the product
roadmap to communicate the expected timing of delivery.
Facilitated Workshop; used to elicit the information required to develop the product roadmap. Because
facilitated workshops support interactivity, collaboration, and improved communications among
participants, the technique is a viable elicitation technique for performing this work.
Feature Model; An existing feature model can be referenced or a new one created to identify a list of
features for the product roadmap.
Product Visioning: a technique used to set the high-level direction for a product or a product release. It
entails conducting conversations with team members to visualize and obtain agreement about what the
team envisions for the product.
Example: Vision Statement or Product Box
Story Mapping: a technique used to sequence user stories, based upon their business value and the
order in which their users typically perform them, so that teams can arrive at a shared understanding of
what will be built.
Stories written during the development of the product roadmap typically are written at a high level and may exist as
epics. Epics are later decomposed into other epics or individual stories.
OUTPUTS
Product Roadmap: a high-level view of product features, along with the sequence in which the features
will be built and delivered.
Product roadmaps should be aligned with the goals and milestones identified as part of the strategic planning effort.
Aspects to be
Adaptive Predictive
Tailored
Name Facilitate Product Roadmap
Visual representation of a roadmap is broken out Roadmaps might show high-level milestones,
by themes and features and may cover a features, or product components. The product
short-term or long-term view. It is revised as new roadmap covers a longer time frame (e.g., 12
features are identified and priorities are adjusted. months) and change is infrequent. When changes
Approach The value of the product changes regularly as are proposed, they need to be assessed for
adjustments are made to the feature set. impact to previously stated and expected value.
Roadmaps can be created for single products or Roadmaps can be created for single products or
for an entire portfolio. for an entire portfolio.
Deliverables Product Roadmap

4.6 ASSEMBLE BUSINESS CASE
1. Business goals and objectives 1. Document analysis 1. Business case

2. Feasibility study results 2. Facilitated workshops 2. Product scope
3. Product roadmap 3. Glossary
4. Recommended solution option 4. Product visioning
5. Required capabilities and 5. Story mapping
features
6. Situation statement
Not all business problems or opportunities require a formal business case. Executives in an organization may approve
portfolio components, programs, or projects based on competitive pressure, government mandate, or executive inclination. In
those cases, a charter may be used to initiate the portfolio component, program, or project.
4.6 ASSEMBLE BUSINESS CASE
A business case should minimally include the following:
• Problem/opportunity. Specify what is prompting the need for action. Use a situation statement or equivalent to
document the business problem or opportunity to be addressed through a portfolio component, program, or
project.
• Analysis of the situation. Describe how a potential solution will support and contribute to the business goals
and objectives. Include root cause(s) of the problem or the main contributors to an opportunity.
• Recommendation. Present the results of the feasibility analysis for each potential option. Specify any constraints,
assumptions, risks, and dependencies for each option. Rank in order the alternatives and list the recommended
one; include why it is recommended and why the others are not.
• Evaluation. Include a plan for measuring benefits realization. This plan typically includes metrics for evaluating
how the solution contributes to goals and objectives. It may necessitate additional work to capture and report
those metrics.
In multiphase initiatives, the business case may be periodically reviewed to ensure that the portfolio component,
program, or project is on track to deliver the business benefits.
INPUTS
Business Goals and Objectives; to provide context regarding what the business expects to achieve by
pursuing the proposed change.
Feasibility Study Results; to obtain an understanding about the proposed solutions that were analyzed
and why each was considered a viable option
Product Roadmap; The key information from the product roadmap is included within the business case
to provide decision makers with insights into how the product is envisioned to evolve over time.
Recommended Solution Option; showcased within the business case, along with the supporting
information that provides the rationalization for its selection.
Required Capabilities and Features; to provide decision makers with insight into which capabilities and
features are required when the recommended solution option being recommended is pursued.
Situation Statement; included in the business case to clearly communicate the problem or opportunity
that the proposed solution is addressing. The situation statement is intended to help those reviewing
the business case to understand the problem or opportunity that the organization is facing and
minimize quick judgments about potential solutions.
Document Analysis; several different sources is reviewed to obtain the relevant information needed to
build the business case.
Facilitated Workshop; a good choice when a team needs to elicit information and amass support to
assemble the business case
Glossary; provides a common vocabulary about terms that the stakeholders and product team may be
unfamiliar with and focuses specifically on the terms requiring clarity to understand the information in
the business case.
Product Visioning; defines the goal and rationale for building the solution is included in the business
case to provide decision makers with the same understanding of the product that the team shares.
Story Mapping; included in the business case, story maps provide insightful information to those
responsible for determining whether to approve the portfolio component, program, or project.
OUTPUTS
Business Case: a documented economic feasibility study, establishing the validity of the benefits, in
terms of value, to be delivered by a portfolio component, program, or project.
The business case is the common link between the business goals and objectives and the portfolio
components, programs, or projects established to execute the business strategy.
Product Scope: defined as the features and functions that characterize a solution.
At this point, product scope is understood at a high level by the capabilities and features associated with
the selected option. Product scope continues to be refined as the product team furthers analysis.
Throughout an initiative, product scope may be revised in response to changing business needs, risks, or
one or more constraints imposed by budget or schedule.
Aspects to be
Adaptive Predictive
Tailored
Not a formally named process; performed as part
Name Assemble Business Case
of project chartering
Create a thorough list of product features,
An initial set of features is developed, with more added over
rigorous estimate, fully defined list of benefits, list
time. Estimates are just detailed enough to continue. Includes
of risks, assumptions, constraints, and
enough information in the business case to move forward with a
dependencies. Requires a formal sign-off against
decision. The feasibility of the solution is validated early by
a fully elaborated business case. Considered a
delivering higher-risk features in early iterations. Return on
higher-risk approach over adaptive methods
investment is attained more
Approach quickly than with predictive methods, as features are delivered
because feasibility is not validated until late in
the initiative. Return on investment is attained at
iteratively. The budget might be focused on how much the
completion of the entire initiative. The business
sponsor has to spend instead of on an assessment of costs.
case includes cost estimates. The benefits are
Scope is determined by addressing highest-prioritized features
estimated and not realized until implementation.
first. As features are added over time, the assessment of
Funding is typically sought to cover the entire
benefits/value changes.
product development cycle.
Lightweight business case that is revisited and
Deliverables revised.
Formalized detailed business case.
4.7 SUPPORT CHARTER DEVELOPMENT
1. Business case 1. Document analysis 1. Charter

2. Product scope 2. Facilitated workshops 2. Shared product information
3. Glossary
4. Interviews
A charter establishes the scope boundaries and creates a documented record of the initiation of the portfolio component,
program, or project.
The charter is used to establish a partnership between the business and the product development team by creating internal
agreements within the organization to ensure the proper delivery of the solution.
INPUTS
Business Case; the business need and the cost-benefit analysis are contained in the business case to
justify and establish boundaries for the portfolio component, program, or project, which is necessary
information when creating a charter.
Product Scope; initial product scope is established by the inclusion of high-level product requirements.
The charter may also include information about out-of-scope features to clearly identify any features
that have been deferred or cut from the scope.
Document Analysis; reviewing organizational charts to identify a potential list of stakeholders or

existing business architecture models to understand areas of the business impacted by the proposed
change are two examples of how existing documentation can be reviewed to elicit information to
develop a charter.
Facilitated Workshops
Glossary
Interviews; scheduled with various stakeholders who possess key information. The information obtained
from interviews can be used to initiate the charter or fill in information gaps when other elicitation
techniques were used previously
OUTPUTS
Charter: establishes the scope boundaries and creates a documented record of the initiation of the
portfolio component, program, or project.
Typically the individual assigned to perform business analysis supports the sponsor with this work. In
adaptive life cycles, a sponsor may create the charter, but a product owner might contribute to the
business analysis work to support charter development
Shared Product Information: consists of the compilation of all the information discussed and shared
across the product team during collaboration.
Building a shared understanding reduces the risk that the product team may develop an end solution
that is out of alignment with stakeholder expectations and enables the team to work more effectively
during development efforts.
Aspects to be
Adaptive Predictive
Tailored
Name Charter Development Support Charter Development
Created as an entire team, before the initiative Created before the initiative starts with detailed
starts with lightweight information about the information about the portfolio components,
initiative, why it is pursued, high-level scope, program, or project; why it is pursued; high-level
capabilities, and success criteria. Decisions made scope; capabilities; and success criteria. Once
Approach during charter development discussions will be approved, the guidelines set forth in the charter
revisited across iterations to ensure that ongoing are followed. The charter information will not
work remains in alignment with the vision set forth change unless the changes being proposed are
at the start of the initiative. approved by those with the authority to do so.
Charter developed to sufficient level to obtain a Formal charter, multipage document. May include
shared understanding about initiative and solution. models that define scope—for example, context
Deliverables May include models that define scope—for diagram. Assembled in a document created from
example, context diagram. a standardized organizational template.
STAKEHOLDER
ENGAGEMENT
STAKEHOLDER ENGAGEMENT OVERVIEW
5.1 Identify Stakeholders
5.2 Conduct Stakeholder Analysis
5.3 Determine Stakeholder Engagement & Communication Approach
5.4 Conduct Business Analysis Planning
5.5 Prepare for Transition to Future State
5.6 Manage Stakeholder Engagement & Communication
5.7 Assess Business Analysis Performance
5.1 IDENTIFY STAKEHOLDERS
1. Elicitation results 1. Brainstorming 1. Stakeholder register

(unconfirmed/confirmed) 2. Interviews
2. Enterprise and business 3. Organizational charts
architectures 4. Process flows
3. Situation statement 5. Questionnaires and surveys
a stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by the
solution; therefore, these individuals and organizations can be termed product stakeholders.
INPUTS
Elicitation Results (Unconfirmed/Confirmed); At any point in time, unconfirmed and confirmed

elicitation results are available as a source of data for identifying stakeholders.
Even results that are unconfirmed can prove valuable when identifying additional areas where potential
stakeholders may exist. Sometimes unconfirmed elicitation results will prompt a follow-up discussion
with stakeholders, which then leads to further discovery of stakeholders and other product-related
information.
Enterprise and Business Architectures; contain models and textual descriptions about roles
throughout the organization. This information can be utilized as a source for identifying stakeholders.
Architecture models can be shared with stakeholders, which may help participants recall missing
stakeholders that need to be added to the stakeholder register.
Situation Statement; this context is required for determining the scope boundary to guide which
stakeholders to include in the stakeholder register.
Brainstorming; it is comprised of two parts: idea generation and analysis. The analysis is conducted to
turn the initial list of ideas into a usable form of information. Brainstorming can be used during
stakeholder identification to build an initial list of stakeholder names.
Interviews; Interviews can be conducted with stakeholders, such as a sponsor or operational managers,
to identify the list of stakeholders who will be involved in one or more aspects of the business analysis
effort.
Organizational Charts: models that depict the reporting structure within an organization or within a
part of an organization.
These models can be reviewed to facilitate the discovery of stakeholder groups or individuals who may
be impacted by or have a potential impact on the solution under analysis.
Process Flows; they are used facilitate discussions around missing stakeholders or to validate a
stakeholder register that has already been started, by reviewing how work is performed or will be
performed.
Questionnaires and Surveys: written sets of questions designed to quickly accumulate information
from a large number of respondents.
Surveys can be used to collect information to establish or maintain a stakeholder list.
OUTPUTS
Stakeholder Register: document that includes the identification, assessment, and classification of
product stakeholders.
Aspects to be
Adaptive Predictive
Tailored
Name Identify Stakeholders
Stakeholders are identified during initial planning, List of stakeholders is identified during business
often using brainstorming, and can be revisited at analysis planning and can be revisited/revised if the
Approach any point throughout the adaptive life cycle as product scope changes or elicitation and analysis
stakeholders are discovered. activities identify new stakeholders.
Might be a list of stakeholders noted in lightweight
Stakeholder register; may require the use of an
Deliverables documentation or models may just involve brainstorm
approved stakeholder register template.
results.
5.2 CONDUCT STAKEHOLDER ANALYSIS
1. Elicitation results 1. Job analysis 1. Updated stakeholder register

(unconfirmed/confirmed) 2. Persona analysis
2. Enterprise and business 3. RACI model
architectures 4. Stakeholder maps
4. Stakeholder register
Refinements to the product scope may result in the addition or removal of stakeholders. Early planning will produce the initial
stakeholder list, but further stakeholder identification will maintain it. When a large number of stakeholders is identified,
stakeholder analysis may involve grouping the stakeholder list by common characteristics, which helps streamline analysis.
Some characteristics of stakeholders to be considered: Attitude, Experience, Interests, Level of Influence
INPUTS
Elicitation Results (Unconfirmed/Confirmed)

Enterprise and Business Architectures
Situation Statement; this context is required during stakeholder analysis to make the determinations
and categorizations about stakeholders and how each is impacted by the recommended solution option.
Stakeholder Register; it contains a list of stakeholders to be analyzed.
Job Analysis: a technique that can be used to identify the job requirements and competencies required
to perform effectively in a specific job or role.
It include details such as a high-level description of the work, a depiction of the work environment, a
detailed list of the activities a person is expected to perform, a listing of the preferred interpersonal
skills, or a list of required training, degrees, and certifications. In order to gain insight into stakeholder
roles.
Persona Analysis: a fictional character created to represent an individual or group of stakeholders,
termed a user class.
It is a technique that can be used to analyze a class of users or process workers, to understand their
needs or product design and behavior requirements.
RACI Model: a common type of responsibility assignment matrix that uses Responsible, Accountable,
Consult, and Inform designations to define the involvement of stakeholders in activities.
RACI model helps minimize confusion and conflicts, especially in areas where responsibilities appear to
overlap.
The RACI model demonstrates that stakeholders can have different levels of involvement at different
points within a product or project life cycle or within different business analysis processes. The RACI
model will highlight single points of accountability and those situations where there is joint
accountability. The RACI classifications are as follows:
R—Role or person “responsible” for performing the task.
A—Role or person “accountable” for the completion/quality of the task; final approver.
C—Role or person who may be “consulted” to obtain information to
I—Role or person who is in some manner impacted by the task, and hence, needs to be “informed” or kept up to
date on the progress and work being performed to complete the task.
RACI Chart Person
Activity Ann Ben Carlos Dina Ed
Create Charter A R I I I
Collect
I A R C C
Requirements
Submit Change
I A R R C
Request
Develop Test
A C I I R
Plan
R: Responsible, A: Accountable, C: Consult, I:
Inform
RACI Model Sample

Interact with
Directly
Impacted
TOOLS AND TECHNIQUES Direct Impact

by Solution
Direct
Involvement
with
Development
Stakeholder Maps: collection of techniques used for analyzing how stakeholders relate to one another
and to the solution under analysis. Several stakeholder mapping techniques exist, including Stakeholder
Matrix and Onion Diagram
External
Stakeholders
OUTPUTS
Updated Stakeholder Register: The results of stakeholder analysis may include the addition or
modification of stakeholder names or the addition or modification of any of the supporting information
pertaining to stakeholder characteristics. Maintaining an accurate stakeholder register is critical to
successful business analysis because the oversight of any one stakeholder could result in the loss of
critical product requirements
Aspects to be
Adaptive Predictive
Tailored
Name Stakeholder or Persona Analysis Stakeholder Analysis
Any number of stakeholder characteristics
Stakeholder interests and influences as related to analyzed; performed during business analysis
expected solution value; performed during initial planning and can be revisited/revised if the
planning or early iterations and can be revisited product scope changes, as elicitation and
Approach prior to the start of an iteration when specific analysis activities identify new stakeholders
details regarding stakeholders are required for the needing to be analyzed, or across the project life
next iteration. cycle as stakeholder attitude and influence levels
may change.
May include stakeholder maps, personas, models, Stakeholder register that includes a listing of
Deliverables or lightweight documentation. stakeholder names and characteristics.
5.3 DETERMINE STAKEHOLDER ENGAGEMENT &
COMMUNICATION APPROACH
1. Situation statement 1. Elicitation techniques 1. Stakeholder engagement and

2. Updated stakeholder register 2. Persona analysis communication approach
3. RACI model
4. Retrospectives and lessons
learned
5. Stakeholder maps
A stakeholder engagement and communication approach often has five components:

1. The level of involvement of each stakeholder
2. The approach for decision making
3. The approach for obtaining approvals
4. How product and project information will be structured, stored and maintained
5. How stakeholders will remain informed about product and project efforts
INPUTS
Situation Statement; provides context to understand the analysis area and guide decisions about the
engagement and communication approach.
Updated Stakeholder Register; The characterization of the stakeholders obtained through stakeholder
analysis is a key factor for determining how a stakeholder will best participate in product development
activities.
Elicitation Techniques;
Brainstorming
Facilitated Workshop
Interviews
Persona Analysis; when stakeholder types have been characterized by personas, continuing analysis to
look for patterns may suggest effective ways to engage and communicate with them
RACI Model; can be used to present the desired level of involvement of each stakeholder or
stakeholder group for different business analysis activities. The results of RACI modeling can be used to
understand assigned responsibilities and how best to engage and communicate with the stakeholders
and groups identified.
Retrospectives and Lessons Learned:
Retrospectives: Meetings scheduled on a regular basis or conducted when a body of work is completed, such as at
the conclusion of an iteration. Retrospectives are most commonly used in adaptive life cycles.
Lessons Learned: Meetings to discuss, analyze, and document feedback about completed project activities. They are
typically conducted by teams that develop solutions using a predictive life cycle.
It use past experience to plan for future work. An optimal stakeholder engagement and communication
approach may consider recommendations provided from past projects or prior iterations, or may apply
past lessons about approaches that worked well for similar product development efforts.
Stakeholder Maps; help with the analysis of stakeholder characteristics such as the power, influence,
impact, and interest of stakeholder groups. Ongoing stakeholder mapping and consideration of the
current and desired level of engagement by stakeholders is part of determining the stakeholder
engagement and communication approach
OUTPUTS
Stakeholder Engagement and Communication Approach: summarizes agreements for the level of
involvement of each stakeholder or stakeholder group; the approaches for making decisions and
obtaining approvals; how product and project information are structured, stored, and maintained in
support of keeping stakeholders and others informed; and how stakeholders are kept up to date about
product and project information and efforts.
Aspects to be
Adaptive Predictive
Tailored
Determine Stakeholder Engagement
Name Not a formally named process and
Communication Approach
The product owner, representing stakeholder needs Planning ideas about whom to engage, what
and preferences for communication, and the rest information to communicate, and how to engage
of the team verbally agree on the format and level and communicate with stakeholders are
of detail of product information to be incorporated into the business analysis plan.
Approach communicated. Stakeholder engagement and Planning activities occur prior to the start of
communication is taken into account as part of elicitation. May specify the format and level of
overall preliminary and ongoing collaborative team detail of product information to be communicated
planning. When team members are colocated, and how that will vary by stakeholder or
most communication can occur in person. stakeholder group.
Stakeholder engagement and communication
Deliverables Not a separate deliverable. approach becomes a component of the business
analysis plan.
5.4 CONDUCT BUSINESS ANALYSIS PLANNING
1. Business analysis performance 1. Burndown charts 1. Business analysis plan

assessment 2. Decomposition model
2. Charter 3. Estimation techniques
3. Enterprise environmental 4. Planning techniques
factors
4. Planning approaches from all
other Knowledge Areas
5. Product risk analysis
The process of conducting business analysis planning has three main objectives:
• Aggregates all of the Knowledge Area approaches into a cohesive set of agreements and decisions about how business
analysis will be conducted,
• Produces an estimation of the level of effort for business analysis activities, and
• Assembles a business analysis plan from the component approaches and the estimates.
INPUTS
Business Analysis Performance Assessment: summarizes what has been learned about the
effectiveness of the business analysis processes and the business analysis techniques used in past
efforts.
As part of planning how to conduct business analysis for an upcoming effort, business analysis
performance assessments may suggest ways to adapt business analysis processes and techniques to
optimize their value in working with a group of stakeholders.
Charter: A charter formally authorizes the existence of a portfolio component, program, or project;
establishes its boundaries; and creates a record of its initiation
It becomes the basis for identifying which aspects of business analysis should be conducted and for
estimating the level of effort involved.
Planning Approaches from All Other Knowledge Areas: the planning approaches from the other
Knowledge Areas can be consolidated into an overall business analysis plan
These components are:
Stakeholder engagement and communication approach
Elicitation approach
Analysis approach
Traceability and monitoring approach
Solution evaluation approach
INPUTS
Product Risk Analysis: includes the consolidated results from identifying and analyzing product risks.
Higher-risk or more complex products and projects may require additional work effort to address the
risks or the complexity.
It includes:
Identified product risks,
List of potential responses,
Relative rating or priority list of risks,
Symptoms and warning signs,
Risks requiring responses in the near term,
Risks for additional analysis and response,
Trends in qualitative analysis results,
Total risk exposure, and
Watch list of low-priority risks.
Burndown Charts: a graphical representation used to count the remaining quantity of some trackable
aspect of a project over time. It help visualize progress, stalled efforts, or backsliding where the
remaining quantity of what is being tracked increases over time.
Decomposition Model: an analysis model used to break down information described at a high level into a
hierarchy of smaller, more discrete parts. typical objects often analyzed with decomposition may include scope,
work products, deliverables, processes, functions, or any other object types that can be subdivided into smaller
elements.
For product development efforts where discrete business analysis tasks and deliverables are estimated separately,
decomposition models can be used to identify what needs to be estimated and ultimately sequenced into a
business analysis work plan
Estimation Techniques: used to provide a quantitative assessment of likely amounts or outcomes, includes:
Affinity estimating. A form of relative estimation, in which team members organize product backlog items into groups
where each product backlog item is about the same size, or where team members use the notion of T-shirt size—e.g.,
small, medium, large, and extra-large—as an estimation scale.
Bottom-up estimating. A method of estimating duration or cost by aggregating the estimates of the lower level tasks.
A decomposition model often identifies these lower-level tasks.
Delphi. Used to support gaining consensus through anonymous estimating as well as to support decision making.
Estimation poker. A collaborative relative estimation technique in which there is an agreed-upon scale used for the
relative estimates.
Relative estimation. A technique for creating estimates that are derived from performing a comparison against a
similar body of work rather than estimating based on absolute units of cost or time.
Wide-Band Delphi. A variation of the Delphi technique where there is more communication and interpersonal
collaboration to bring convergence to widely differing estimates that have been developed separately for the same task
or product backlog item by a number of different individuals.
Planning Techniques:
Product backlog. the list of all product backlog items, typically user stories, requirements, or features, that need to
be delivered for a solution. Individual items in the backlog are estimated as part of selecting, in prioritized order,
those items that the team is about to commit to deliver in an upcoming iteration.
Rolling wave planning. an iterative planning technique in which the work to be accomplished in the near
term is planned in detail, while the work in the future is planned at a higher level.
Story Mapping. can help suggest when more effort may need to be spent on analysis.
Work breakdown structure (WBS). A planning technique for projects using a predictive life cycle. WBS is a
hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the
project objectives and create the required deliverables.
OUTPUTS
Business Analysis Plan: It defines the business analysis approach through the assembly of the sub-
approaches across all Knowledge Areas. A business analysis plan can include an estimation of level of
effort for business analysis activities. It covers the entire business analysis approach, from stakeholder
engagement to decisions about how to manage requirements.
It is broader than a requirements management plan, which focuses on how requirements will be elicited,
analyzed, documented, and managed. Whether formally documented or not, the business analysis plan
provides a summary of the agreements reached for all of its components.
Aspects to be
Adaptive Predictive
Tailored
Not a formally named process; performed as
Name part Conduct Business Analysis Planning
of initial planning or iteration 0
Plan includes business analysis tasks, level of
Some teams formulate their approach to business
effort, roles, and responsibilities. Prior to
analysis planning by deciding how they will
beginning any elicitation activities, the business
conduct discovery and backlog refinement.
analysis plan is assembled using the component
The level of effort needed for business analysis is
Approach rarely estimated separately from the time needed
plans from other Knowledge Areas. The level of
effort required for elicitation, analysis, traceability
to design and develop or enhance the product.
and monitoring, and evaluation activities is
Instead, it is part of the overall planning for future
estimated. Approval or sign-off is obtained for the
iterations.
entire plan.
Rarely a separate deliverable. Some teams
capture specific analysis tasks when creating the
list of tasks for each iteration to a burndown chart
or add something to the project charter about Business analysis plan, including work breakdown
Deliverables business analysis as part of authorizing the structure.
resources for the project.
Some results of business analysis planning are
reflected in the definition of ready.
5.5 PREPARE FOR TRANSITION TO FUTURE STATE
1. Business case 1. Elicitation techniques 1. Readiness assessment

2. Current state assessment 2. Group decision-making 2. Transition plan
3. Product risk analysis techniques
4. Product scope 3. Job analysis
5. Requirements and other 4. Prioritization schemes
product information 5. Process flows
6. Solution design 6. SWOT analysis
7. Stakeholder engagement and 7. User story
communication approach
Preparing for transition involves assessing the readiness of the organization to successfully transition from product
development to operations and creating a plan to identify the requirements for making the transition successful.
The readiness assessment is used to identify any gaps in readiness that are considered risks to achieving the end state, along
with risk responses for addressing them
INPUTS
Business Case; provides the context for the transition and a basis for prioritizing transition activities.
Current State Assessment; can be examined in conjunction with the solution design to identify
differences between them, so as to consider how to handle those differences.
Product Risk Analysis; Higher-risk or more complex products and projects may require additional work
effort to address the risks or the complexity as part of the transition.
Product Scope; understanding the product scope may be the basis for deciding how the transition
should proceed and what special resources and coordination will be needed.
Requirements and Other Product Information: include all information about a solution and are the
culmination of results from elicitation and analysis activities.
transition requirements are part of the requirements and other product information
Solution Design: specifications and diagrams, typically based on business analysis findings, which
describe how the solution will be implemented.
It is a crucial input for preparing for the transition to the future state, as it determines the future state.
Stakeholder Engagement and Communication Approach; identifies which stakeholders should be
involved in preparing for the transition and how best to collaborate with them. Without the participation
of key stakeholders in transition activities, transition work may be poorly executed.
Brainstorming
Interviews
Group Decision-Making Techniques; can help reach decisions about the best approaches for moving a
solution from a development environment into an operational environment
Job Analysis; It can be used to determine training needs, as a precursor to writing a job posting, or to
support a performance appraisal process. As part of preparing for the transition to the future state, job
analysis is used to think through what is needed to hire and train people for new roles that may be
needed to support the future state.
Prioritization Schemes: different methods used to prioritize requirements, features, or any other
product information.
It may be used as part of preparing for a transition in any situation where it becomes necessary to
conduct a transition in segments.
Process Flows; Some of the process flows comprising the requirements and other product information
provide the basis for training materials on the new procedures that will be in place once the transition
takes place.
SWOT Analysis; can provide a way for the participants to express their expectations and concerns for
the transition at a high level, by stating these concerns as strengths, weaknesses, opportunities, and
threats. Readiness issues may surface from the weaknesses and threats that are identified
User Story: a method to document stakeholder requirements from users’ point of view with a focus on
the value or benefit achieved by users with the completion of that story.
Transition user stories may focus on topics such as expectations for training materials and
communications, about the rollout of the future state, or on new procedures.
OUTPUTS
Readiness Assessment: A determination of the ability and the interest of an organization to transition
to the future state. The readiness assessment is used to identify any gaps in readiness that are
considered risks to achieving the end state along with risk responses for addressing them.
Transition Plan: It is based on the readiness assessment as well as the transition strategy. From a
business analysis perspective, a transition plan encompasses actionable and testable transition
requirements.
Aspects to be
Adaptive Predictive
Tailored
Name Prepare for Transition to Future State
For small, incremental releases to production, there
A readiness assessment and transition requirements
will be transition tasks in a story or separate
are used to determine a transition strategy and as the
transition stories to push the release to production.
basis of transition planning. It includes information to
For implementations in large-scale environments,
Approach many or all of the predictive considerations for
support operational procedures, training collateral,
service-level agreements, rollout collateral,
transition may be used, even in situations where
coordination with other releases, and contingency
product segments were delivered for feedback as
plans.
soon as they were production ready.
Format can vary from being part of the “definition of
done” or transition user stories all the way to formal
plans for large-scale product releases.
For some organizations, rather than a plan per se, A readiness assessment and transition plan,
Deliverables thinking about transition may manifest itself in setting potentially including a readiness checklist and a
up a reserved block of time or specific iteration to schedule.
accomplish the transition, coordinated with the
operational area that will own the solution, including
time to clean up technical debt.
5.6 MANAGE STAKEHOLDER ENGAGEMENT AND
COMMUNICATION
1. Stakeholder engagement and 1. Elicitation techniques 1. Improved stakeholder

communication approach engagement and
2. Updated stakeholder register communication
Manage Stakeholder Engagement and Communication focuses on monitoring the participation of stakeholders in business
analysis activities, ensuring that stakeholders remain engaged throughout and assessing whether their participation is
sufficient for them to have a clear understanding of the requirements and other product information.
INPUTS
Stakeholder Engagement and Communication Approach; The agreements within the stakeholder
engagement and communication approach provide the norms for ensuring that stakeholders remain
involved and continue to actively participate and that communication is open and ongoing throughout
the entire product development life cycle.
Updated Stakeholder Register; The characterization of the stakeholders is a key factor for assessing
whether or not the engagement of and communication with a particular stakeholder is optimal at any
point in time.
Elicitation Techniques; reveals the perspective of the stakeholders and enables product teams to
brainstorm solutions to any communication or engagement challenges that may arise. When eliciting
information about engagement or communication challenges, care should be taken to involve those
who are responsible for removing roadblocks. In some organizations, politics or perception may make it
prudent to avoid separating stakeholder engagement and communication for business analysis from
overall stakeholder engagement and communication concerns.
OUTPUTS
Improved Stakeholder Engagement and Communication; the result of directing efforts and team
collaboration toward addressing business analysis engagement and communication concerns as they
arise. For challenges that arise, those responsible for business analysis often address the concerns by
closely working with and relying upon those who have management responsibilities, authority, and/or
the responsibility to remove roadblocks.
Aspects to be
Adaptive Predictive
Tailored
Manage Stakeholder Engagement and
Name Not a formally named process
Communication
Typically use regularly scheduled (often daily), very
short (no more than 15 minutes) team meetings
Business analysts raise stakeholder engagement
to uncover existing or potential roadblocks where
concerns with stakeholders directly or at regularly
Approach stakeholder engagement and communication is
scheduled status meetings, risk meetings, and in
not optimal; appropriate team members then work
conversations with project management.
to immediately remove these roadblocks as they
are uncovered.
Improved engagement and communication as
Possible changes to “ground rules” or other written
Deliverables rules of engagement.
reflected in changes to approaches, plans, issue
logs, and other documents.
5.7 ASSESS BUSINESS ANALYSIS PERFORMANCE
1. Business analysis plan 1. Burndown charts 1. Business analysis performance

2. Business analysis organizational 2. Elicitation techniques assessment
standards 3. Process flows
3. Business analysis performance 4. Retrospectives and lessons
metrics and measurements learned
4. Business analysis work products 5. Root cause and opportunity
analysis
6. Variance analysis
A primary purpose of assessing business analysis performance is to gain insights from product development experiences to
consider which business analysis tools and techniques are working well and which present challenges.
INPUTS
Business Analysis Plan; an be compared to what was actually performed to obtain insights for planning
better in the future. A business analysis work plan, a subcomponent of a business analysis plan, may
include level of effort estimates, and those estimates can be compared to the actual work effort to help
the team improve future estimates.
Business Analysis Organizational Standards: include expectations for how business analysis will be
conducted and what tools might be used to support business analysis efforts.
These standards may also include key performance indicators (KPIs) established at an organizational
level for business analysis. Business analysis organizational standards are part of the benchmark from
which business analysis performance can be assessed.
Business Analysis Performance Metrics and Measurement: qualitative or quantitative measures or
inferences used to evaluate the effectiveness of business analysis practices.
Some of the metrics tie to the usage and the perception of the effectiveness of the business analysis
practices themselves; others focus on problems with requirements as an indicator of underlying
problems with business analysis practices.
Business Analysis Work Products: Any unique and verifiable result, produced throughout the course of
performing business analysis activities, which is provided to team members and stakeholders to perform
future work, decision making, or complete a process, phase, or initiative.
Burndown Charts; It may reveal stalled efforts, or negative progress after several iterations have been
completed.
Example: slowdown in team velocity may be observed in a slowdown or stall in the burndown of the
product backlog items remaining. For solutions delivered using an adaptive approach, such a slowdown
can mean that the user stories are not sliced or defined correctly or are not sliced in a way that defines
and delivers increments of value.
Brainstorming
Interviews
Questionnaires and Surveys
Process Flows; Drawing and analyzing the flow of business analysis activities can support the
identification of possible process-related causes of problems
Retrospectives and Lessons Learned
Root Cause and Opportunity Analysis; can be used to discover the underlying reasons behind
business analysis performance challenges or to identify the reasons why some business analysis
practices are working very well
Variance Analysis: technique for determining the cause and degree of difference between the baseline
and actual performance.
Irrespective of product life cycle, as part of verifying requirements, when there are significant differences
between the expected format and content of a business analysis work product and what was actually
produced, variance analysis may be applied to consider the causes of the differences.
OUTPUTS
Business Analysis Performance Assessment: summarizes what has been learned about the
effectiveness of the business analysis processes in general and of the business analysis techniques that
have been used in particular.
In some cases, it may also reflect on the skill of the individuals who are conducting business analysis or
the degree or quality of participation of stakeholders.
Practices that are working well at the program or project level can be recommended for elevation to
best practices and standards for use by the entire organization for future programs and projects.
For those tools and techniques that present challenges, recommendations may be made for
improvements or for the replacement of the challenging tools and techniques with other tools and
techniques.
Performance concerns related to individuals conducting business analysis or stakeholder participants are
also identified and can be addressed with training, coaching, or, when necessary, assignment of other
individuals to focus on business analysis. Some organizations track the proposed recommendations in
logs.
Aspects to be
Adaptive Predictive
Tailored
Assess Business Analysis Performance
Name part
or Conduct Lessons Learned
of Conducting Retrospectives
The business analyst contributes to lessons learned as
part of project management’s monitoring and control,
at the conclusion of a work effort, at milestones, and
Follows the principle of “inspect and adapt,” where as indicated by ongoing events. Business analysts may
teams conduct regular and frequent reviews of also analyze performance individually using metrics
practices throughout the development of the defined in planning.
solution. These reviews are conducted at least at Follow-up on lessons learned can take place whenever
Approach the end of each iteration and take action on these sessions occur during product development.
findings to adjust business analysis practices for When assessments occur after product development is
the next iteration. The changes are implemented in well under way, or after it has been completed, the
the very next iteration. recommendations are more likely to be applied to
future product
development efforts rather than the one for which
the assessment has been made.
Recommendations for changes to practices can be
documented as a separate business analysis
Recommendations for changes to practices or assessment document. In organizations with more
Deliverables participants may be communicated verbally or formal processes or governance, they could be
documented. documented with modifications to workflows, work
instructions, templates, approach, or
configuration in requirements management tools.
ELICITATION
ELICITATION OVERVIEW
6.1 Determine Elicitation Approach
6.2 Prepare for Elicitation
6.3 Conduct Elicitation
6.4 Confirm Elicitation Results
6.1 DETERMINE ELICITATION APPROACH
1. Product scope 1. Brainstorming 1. Elicitation approach

2. Situation statement 2. Interviews
3. Stakeholder engagement and 3. Retrospectives and lessons
communication approach learned
4. Updated stakeholder register
The key benefits of this process are efficient use of stakeholder time, effective stakeholder collaboration, and an organized
approach to elicitation.
INPUTS
Product Scope; provides context and defines the boundaries to determine what information to elicit
with the goal of further detailing the scope items.
Situation Statement; providing context when determining what information to elicit.
Stakeholder Engagement and Communication Approach; there may be certain stakeholder
preferences that signal which elicitation techniques are best to use for a particular stakeholder or
stakeholder group.
Stakeholder Register; a stakeholder’s role on a project or position within the organization may
determine which details and/or perspectives he or she can provide. One might also conclude that senior
stakeholders may have less availability and be more difficult to schedule for group elicitation activities.
Brainstorming
Interviews
Retrospectives and Lessons Learned; leverage past experiences to plan for the future. combined with
experience and expert judgment, can be used to tailor the elicitation approach to ensure the best fit for
the project
OUTPUT
Elicitation Approach: describes how Elicitation will be performed, what information to elicit, where to
find that information, how to obtain the information, and when to conduct the elicitation activities
It can be documented or it can be a thought process performed to prepare for the forthcoming
elicitation effort. Whether formally documented or not, the decisions and thought process used to plan
elicitation activities can be shared with the project team to ensure that everyone is aware of the
forthcoming activities and their role. The elicitation approach may be referred to as an elicitation plan in
more formal life cycles.
Aspects to be
Adaptive Predictive
Tailored
Name Not a formally named process Determine Elicitation Approach
Though some high-level planning might occur,
most of the elicitation approach is defined early in
each iteration for the elicitation that will occur
during that iteration. Because elicitation is often A high-level elicitation approach is defined early,
performed to refine product backlog items up to a during a planning phase. The elicitation approach
Approach few iterations ahead of being developed, the is refined throughout the portfolio, program, or
elicitation approach defined is often for more than project.
the work being developed in the current iteration.
Collaborative elicitation techniques may be
selected to obtain information from stakeholders.
Not a separate deliverable. The elicitation
approach is not formally documented but is
Detailed elicitation approach residing in a
Deliverables complete when the team obtains a shared
business analysis plan.
understanding of what is expected during the
elicitation activities.
6.2 PREPARE FOR ELICITATION
1. Elicitation approach 1. Document analysis 1. Elicitation preparation materials

2. Product scope 2. Interviews
3. Requirements and other
product information
5. Stakeholder engagement and
For large elicitation engagements, the preparation may actually be more time-consuming than the elicitation activity itself. For
elicitation activities that do not involve other people, such as document analysis, the preparation might be brief.
Preparing for elicitation include the following activities:

1. Determine the Objective
2. Determine the Participants
3. Identify the Resources
4. Identify the Questions for elicitation
5. Set the Agenda
6. Schedule the Elicitation activity
INPUTS
Elicitation Approach; Elicitation activities will require preparation to ensure that they provide value. The
participant list can also be derived from elicitation planning efforts.
Product Scope; provides context to determine the objectives of the elicitation activity and to
subsequently prepare the questions and set the agenda
Requirements and Other Products Information; provide context to determine the objectives of the
elicitation activity and to subsequently prepare the questions and set the agenda. Previously elicited
requirements or models may be used to guide the elicitation activity. Visual representations are often
easier for most audiences to follow along with and provide feedback on.
Situation Statement; used to determine the objective of the elicitation activity and to subsequently
prepare the questions and set the agenda.
Stakeholder Engagement and Communication Approach; It is revisited when preparing for the
elicitation activity, in case the elicitation needs to be tailored to specific stakeholder preferences.
Document Analysis; it can be used to obtain information that is readily available within existing
document repositories, reducing the amount of elicitation time needed with stakeholders. The results of
document analysis can be used to support elicitation preparation.
Interviews; Preliminary interviews may support elicitation preparation by clarifying objectives with those
who may take part in elicitation activities or discussing preparation steps and materials so participants
know what will be expected of them prior to and during elicitation.
OUTPUTS
Elicitation Preparation Materials: items created to maximize the probability of meeting elicitation
activity objectives, while optimizing the time spent with elicitation participants.
Elicitation preparation materials may be formal or informal, depending on the preference of the
facilitator. Preparation materials may include:
Elicitation activity objectives,
An agenda,
Background information,
Questions to be discussed,
Ground rules and/or instructions to support an elicitation technique, and
Presentation materials and/or product information, including models, to help structure the elicitation activity.
Aspects to be
Adaptive Predictive
Tailored
Name part Prepare for Elicitation
of Backlog Refinement or Elaboration
Preparation is performed whenever elicitation is to
be conducted. Elicitation of high-level product Preparation is performed whenever elicitation is to
information occurs within iteration 0, and be conducted. Elicitation of high-level product
elicitation of more detailed product information information occurs at the portfolio and program
Approach occurs within subsequent iterations. Elicitation level, and elicitation of more detailed product
within an iteration may clarify information for the information occurs within an analysis phase of
current iteration or elaborate on product a project.
information one to two iterations ahead.
Elicitation is frequent, with the goal of elaborating
Scope of elicitation is larger; preparation
Deliverables just enough information; preparation materials are
materials may be more detailed.
lightweight.
6.3 CONDUCT ELICITATION
1. Elicitation preparation materials 1. Brainstorming 1. Unconfirmed elicitation results

2. Product scope 2. Collaborative games
3. Situation statement 3. Document analysis
4. Facilitated workshops
5. Focus groups
6. Interviews
7. Observation
8. Prototyping
9. Questionnaires and surveys
There are three stages during an elicitation activity that are applicable regardless of the elicitation technique used:
• Introduction. The introduction sets the stage, sets the pace, and establishes the overall purpose for the elicitation activity.
• Body. The body is where the questions are asked and the answers are given or uncovered.
• Close. The close provides a graceful termination to the particular activity.
INPUTS
Elicitation Preparation Materials; used while conducting elicitation to structure and guide the
elicitation activity
Product Scope; used when developing the objectives for the elicitation activity and when conducting
elicitation to ensure that discussions remain on topic.
Situation Statement; to ensure shared understanding among elicitation participants about the topics to
be discussed and will help guide elicitation discussions
Brainstorming
Collaborative Games: a collection of elicitation techniques that foster collaboration, innovation, and
creativity to achieve the goal of the elicitation activity.
There are many types including:
Product Box: technique that uses game play to focus on the features of a product that are important to the customer.
Speedboat: technique that uses game play to elicit information about product features that customers/stakeholders
find problematic. A picture of a boat with several anchors is drawn on a large sheet of paper
Spider web: technique used to discover unknown relationships between the product being analyzed and other
products. The technique helps product teams identify competitive aspects of a product and may lead to changes in
product scope.
Document Analysis; it can provide the following benefits:

Information received from individuals may be subjective or individuals may not have an accurate view of the
information, whereas documented information tends to be more objective;
Documents may contain information that no one individual has;
Written documentation may provide more background and explanations than an individual explaining the same
material;
Documents may have enough information to use as a starting point, thereby saving significant stakeholder time
during in-person elicitation activities; and
Up-to-date documentation can be a good source of information regarding the structure and capabilities of any
product.
Facilitated Workshops; considered a primary technique for quickly defining product information across
multiple domains and reconciling stakeholder differences. Because of their interactive group nature,
well-facilitated sessions can build trust, foster relationships, and improve communication among the
participants, which can lead to increased stakeholder consensus.
Focus Group: bring together prequalified stakeholders and subject matter experts (SMEs) to learn about
their expectations and attitudes about a proposed solution. Focus groups provide an opportunity to
obtain feedback directly from customers and/or end users.
Interviews; used to build relationships and trust with stakeholders by taking the time to understand
their situation and any potential pain points. Interviews conducted for this purpose may not have
documented results
Observation: an elicitation technique that provides a direct way of obtaining information about how a
process is performed or a product is used by viewing individuals in their own environment performing
their jobs or tasks.
Prototyping; provides an opportunity to validate a conceptual working solution against an existing set
of requirements to look for potential gaps in requirements. Common types:
Storyboarding: technique that shows sequence or navigation through a series of images or illustrations.
Wireframes: Diagrams that represent a static blueprint or schematic of a user interface used to identify basic
functionality.
Evolutionary: A prototype that is the actual finished solution in process.
Questionnaires and Surveys
Wireframe Sample Storyboarding Sample

OUTPUTS
Unconfirmed Elicitation Results: consist of the information obtained from completed elicitation
activities. The results of elicitation activities may be documented either formally or informally.
Documentation can range in formality, from capturing a snapshot of a whiteboard that contains
preliminary requirements to information recorded in requirements management tools.
The primary documented result is a set of elicitation notes that comprise a wealth of information for
performing other business analysis processes.
The results may come in the form of sketches, diagrams, models, flipcharts, photos, videos, audio
recordings, sticky notes, or index cards, to name a few.
Aspects to be
Adaptive Predictive
Tailored
Name Backlog Refinement or Elaboration Conduct Elicitation
Elicitation is frequent, with the goal of elaborating
just enough information. Elicitation of high-level
Elicitation of high-level product information
product information occurs to develop the backlog,
occurs at the portfolio and program level, and
and elicitation of more detailed product
elicitation of more detailed product information
Approach information happens within subsequent iterations.
occurs within an analysis phase of a project.
Elicitation within an iteration may be done to
However, as changes are made in later phases,
clarify information for the current iteration or to
elicitation processes are repeated.
elaborate on product information one to two
iterations ahead.
Shared understanding of elicitation results may
Comprehensive and documented elicitation
Deliverables not be documented, documented just enough, or
results.
represented in models.
6.4 CONFIRM ELICITATION RESULTS
1. Elicitation preparation materials 1. Document analysis 1. Confirmed elicitation results

2. Unconfirmed elicitation results 2. Glossary
3. Interviews
4. Observation
5. Walkthroughs
Elicitation results may need to be:

• Refined and/or corrected and extraneous information eliminated;
• Organized, categorized, and consolidated;
• Compared against previously elicited information, and discrepancies followed up on during future elicitation;
• Converted to an appropriate level of formality based on stakeholder needs; and
• Packaged for distribution.
INPUTS
Elicitation Preparation Materials; information, may be updated based on information learned during
elicitation and compared with the elicitation results to determine whether there are issues or gaps that
require additional elicitation
Unconfirmed Elicitation Results: the results from elicitation, documented in various formats, are
consolidated and organized in a manner that can be reviewed, understood, and validated by those who
provided the information or against the original source materials. Unconfirmed elicitation results evolve
into confirmed elicitation results upon the completion of this process.
Document Analysis; used to compare elicitation results to historical information to confirm accuracy
Glossary; helpful tool when confirming elicitation results to enable product teams to reach agreement
on the meaning of terms and to identify terms that are being used differently across the product team,
organization, or industry
Interviews; when necessary, follow-up interviews may be conducted to obtain confirmation of
elicitation results and clarifications on any discrepancies from an elicitation activity.
Observation; used to cross-check non-observation elicitation results with actuality
Walkthroughs: peer review in which the author of the materials walks the peer reviewers through the
authored information.
May be conducted to review the results of elicitation to obtain confirmation that the results are accurate
at this point in time, or to clarify any discrepancies raised
OUTPUTS
Confirmed Elicitation Results: consist of the business analysis information obtained from completed
elicitation activities.
Confirmed elicitation results signify that the product team has reached a common understanding and
agrees to the accuracy of the information elicited. Confirmed elicitation results may be obtained after a
group of stakeholders reviews the materials provided upon completion of elicitation or they can be
obtained concurrently as elicitation is performed.
Aspects to be
Adaptive Predictive
Tailored
Name part Confirm Elicitation Results
Elicitation may be conducted and confirmed
Elicitation is conducted and the results confirmed
Approach concurrently.
concurrently or confirmation may occur at a point
in time after elicitation has been completed.
Acknowledgment that elicitation results are
Shared understanding of elicitation results may be
Deliverables documented or represented in models.
accurate. Elicitation results are typically
comprehensive and documented.
ANALYSIS
ANALYSIS OVERVIEW
7.1 Determine Analysis Approach
7.2 Create and Analyze Models
7.3 Define and Elaborate Requirements
7.4 Define Acceptance Criteria
7.5 Verify Requirements
7.6 Validate Requirements
7.7 Prioritize Requirements and Other Product Information
7.8 Identify and Analyze Product Risks
7.9 Assess Product Design Options
7.1 DETERMINE ANALYSIS APPROACH
1. Elicitation approach 1. Brainstorming 1. Analysis approach

2. Product scope 2. Document analysis
3. Situation statement 3. Retrospectives and lessons
4. Traceability and monitoring learned
approach
When using a predictive delivery approach, the analysis approach should also define the requirements life cycle for the
portfolio, program, or project. The requirements life cycle represents the various phases or states through which a
requirement moves as it is defined, elaborated, verified, validated, and prioritized.
When using an adaptive delivery approach, the requirement states may be more implicit. User stories may be stated as not
ready, ready, or done, where done is coupled to the delivery and acceptance of that portion of the solution that satisfies the
requirement.
INPUTS
Elicitation Approach; used as a starting point for determining some aspects of the analysis approach.
The planned elicitation techniques and their outputs might influence which analysis techniques are
applicable. The timing of individual elicitation activities will affect when related analysis activities happen.
Product Scope; defines the boundaries within which analysis takes place
Situation Statement; provides context about the problems or opportunities being analyzed to help
determine what information will need to be analyzed and how it might need to be analyzed. Business
analysts are confronted with different types of information, and the situation statement helps separate
out irrelevant information that might interfere with proper analysis.
Traceability and Monitoring Approach: defines the traceability and change management processes
for the portfolio, program, project, or product.
One of the components of that approach is how the requirements, models, and other product
information relate to one another, which is an important input for selecting analysis techniques that
support creating models, using the models together, and identifying requirements from the models.
Brainstorming
Document Analysis; can help determine which existing models in the organization could be used as a
starting point for analysis, thereby affecting which analysis activities need to be performed and how long
they will take.
OUTPUTS
Analysis Approach: describes how analysis will be performed; how to verify, validate, and prioritize
requirements and other product information; how risks will be identified and analyzed; how design
options will be assessed; and which techniques and templates are expected to be used to perform any
analysis
The analysis approach includes which requirements attributes need to be captured and how the
requirements architecture impacts analyzing models. It also describes what other information or models
from the organization might be used during analysis. This output will likely be updated throughout the
course of the portfolio, program, or project.
Aspects to be
Adaptive Predictive
Tailored
Name Not a formally named process Determine Analysis Approach
Describes the types of product information to be
defined and refined during analysis. Though some
A high-level analysis approach is defined early,
high-level planning might occur, most of the
during a planning phase. The analysis approach is
analysis approach is defined just before or early in
Approach each iteration for the analysis that will occur
refined throughout the portfolio, program, or
project. It describes types of product information
during that iteration. Analysis performed in one
to be defined and refined during analysis.
iteration might not be used by the development
team until a later iteration.
Detailed analysis approach resides in a business
Deliverables Not a separate deliverable.
analysis plan.
7.2 CREATE AND ANALYZE MODELS
1. Analysis approach 1. Context diagram 1. Analysis approach
2. Confirmed elicitation results 2. Data dictionary
3. Requirements and other 3. Data flow diagram
product information 4. Decision tree and decision table
5. Ecosystem map
6. Entity relationship diagram
7. Event list
8. Feature model
9. Goal model and business
objectives model
10. Modeling elaboration
11. Organizational chart
12. Process flows
13. Prototypes, wireframes, and
Models are visual representations of display-action-response models
information, in the form of diagrams, 14. Report table
15. State table and state diagram
tables, or structured text, that effectively 16. Story mapping
arrange and convey a lot of information 17. System interface table
in a concise manner 18. Use case diagram
19. User interface flow
7.2 CREATE AND ANALYZE MODELS
Category Definition Example Models
• Goal and business objectives model
• Ecosystem map
• Context diagram
• Feature model
Models that structure and organize the features,
• Organizational chart (described in Business Analysis Planning)
Scope Models functions, and boundaries of the business domain
• Use case diagram
being analyzed
• Decomposition model (described in Business Analysis Planning)
• Fishbone diagram (described in Needs Assessment)
• Interrelationship diagram (described in Needs Assessment)
• SWOT diagram (described in Needs Assessment)
• Process flow
Models that describe business processes and ways in
Process Models • Use case
which stakeholders interact with those processes
• User story
Models of concepts and behaviors that define or • Business rules catalog
Rule Models constrain aspects of a business in order to enforce • Decision tree
established business policies • Decision table
• Entity relationship diagram
• Data flow diagram
Models that document the data used in a process or
Data Models • Data dictionary
system and its life cycle
• State table
• State diagram
• Report table
• System interface table
Models that assist in understanding specific systems
Interface Models • User interface flow
and their relationships within a solution
• Wireframes
• Display-action-response
INPUTS
Analysis Approach; as the models are analyzed, new model types might need to be created and the
analysis approach may need to be updated. The analysis approach also describes the requirements
architecture that describes which models are most likely to relate to one another for modeling
elaboration.
Confirmed Elicitation Results; As the models are created and analyzed for gaps, the business analyst
may discover additional questions about scope, processes, rules, data, or interfaces that will require
additional elicitation.
Requirements and Other Product Information; The subset of this information that is most relevant as
an input is any previously defined requirements, acceptance criteria, and other analysis models. As work
progresses, the volume of requirements and other product information will grow or be refined,
providing additional context to create new models or analyze existing ones.
Context Diagram: a scope model that shows all the direct system and human interfaces to systems
within a solution. A context diagram clearly depicts the in-scope systems and any inputs or outputs,
including the systems or actors providing or receiving them.
Data Dictionary: a data model that lists the data fields and attributes of those fields for a data object.
The data fields are additional details for the data objects in an entity relationship diagram
Data Flow Diagram: a data model that is used to describe the movement of data between external
entities, data stores, and processes. External entities can be actors or systems. Data flow diagrams show
the data inputs and outputs for each process.
Decision Tree and Decision Table: rule models that show a series of decisions and the outcomes to
which the decisions lead. Decision trees and tables are often used to model business rules.
Decision trees visually show the flow of decisions and choices that lead to an outcome and can show
ordered decisions.
Decision tables are useful for ensuring that the business analyst has considered all possible
combinations of decision scenarios and related outcomes.
Ecosystem Map: a scope model that shows all the relevant systems, the relationships between systems,
and optionally, any data objects passed between them. The systems are logical systems (business view);
therefore, they may not match physical systems (implementation view) in architectural diagrams.
Entity Relationship Diagram: also called a business data diagram, is a data model that shows the
business data objects or pieces of information of interest in a product and the cardinality relationship
between those objects.
Cardinality is the number of times that one entity occurs in relationship to the other entity in the
relationship, and whether the relationship is required or optional.
Event List: a scope model that describes any external events that trigger solution behavior. Event lists
help define the in-scope events that the solution has to react to or handle. An event response table is a
related model that extends the event list to describe the system’s response to any event triggers.
Feature Model: a scope model that visually represents

all the features of a solution arranged in a tree or
hierarchical structure.
Most projects have features at varying levels; the top-
level features are called Level 1 (L1) features, followed
by Level 2 (L2) features, and so on. Feature models are
helpful to show how features are grouped together
and which features are sub-features of other ones.
Goal Model and Business Objectives Model: scope models that organize and reflect the goals and
business objectives in relation to other product information.
Goal models typically show the stakeholder goals for a solution, with any supporting or conflicting goal
relationships indicated.
Business objectives models relate the business problems, business objectives, and top-level features.
Modeling Elaboration: technique that uses the collection of models together to further identify gaps,
inconsistencies, or redundancies in product information.
The requirements architecture, as defined in the analysis approach, will help determine which models are
best to use together.
Traceability matrix. a table that connects or traces links between items.
Most commonly, business analysts use traceability matrices to trace requirements backward to features and business
objectives or forward to code or other development artifacts or test cases.
Interaction Matrix. lightweight version of a traceability matrix that is used to figure out whether requirements are
sufficiently detailed or if any entities are missing
The main difference between the two types of traceability matrices is that an interaction matrix represents a specific
point in time. As a result, interaction matrices are not maintained and are simply used to evaluate requirements at
any given time during a project.
CRUD Matrix. defined as create (C), read (R), update (U), and delete (D), represents the operations that can be
applied to data or objects. CRUD matrices describe who or what has permission to perform each of the CRUD
operations on elements, such as data or user interface screens.
Traceability Matrix Sample

Interaction Matrix Sample
CRUD Matrix Sample

Organizational Chart: scope model that shows the reporting structure within an organization or within a
part of an organization.
It can help when looking to identify users or groups of users that have security and permissions
requirements.
Process Flows: process model category and are used to visually document the steps or tasks that people
perform in their jobs or when they interact with a solution.
Might be created as both as-is and to-be representations of the business processes so that the changes or
enhancements to current solutions can be shown visually. The process flows might be accompanied by additional
details to ensure that stakeholders can understand what occurs with each step.
Prototypes, Wireframes and Display-Action-Response Models: they are all interface models.
Prototype is a representation of the expected solution before it is built
Wireframe is a type of prototype, specifically a mockup of user interface design, used to show what a screen should
look like
Display-action-response model uses a tabular format to describe page elements and the functions attached to each
Report Table: interface model that describes detailed requirements for a single report. Report tables
contain both information about the report as a whole, such as the report name or decisions made from
the report, and field-level information, such as which data fields are displayed and any calculations.
State Table and State Diagram: data models that show the valid states of an object and any allowed
transitions between those states.
State tables are most commonly used for analysis to ensure that all transitions are covered, while state diagrams are
easier for stakeholders to visualize the valid transition flow.
Story Mapping: a technique used to sequence user stories, based upon their business value and the
order in which their users typically perform them, so that teams can arrive at a shared understanding of
what will be built.
Story maps include two foundational parts: the backbone and the walking skeleton.
The backbone is the minimum set of capabilities that absolutely have to be in the first release for the solution to
serve its purpose. That set of capabilities is sometimes called the minimum viable product (MVP). The capabilities are
often described as features, epics, or user stories.
The walking skeleton is the full set of end-to-end functionality that the stakeholders require for the solution to be
accepted or considered functional. This set is usually described by a set of user stories and is sometimes called the
minimum marketable features (MMF).
System Interface Table: interface model that captures all the detailed level requirements for a single
system interface. System interface tables are created for each system that interfaces to the solution
system
Use Case Diagram: scope model that shows all the in-scope use cases for a solution. Creating use case
diagrams involves identifying a list of both the users of the solution and the possible scenarios of how
each user will use the solution.
User Interface Flow: an interface model that

displays specific user interfaces and commonly used
screens within a functional design and plots out
how to navigate between them.
OUTPUTS
Analysis Models: are visual representations of product information. The analysis models might be draft
or fully completed models.
Analysis models reflect the total sum of all the models created, even though they might not be created
at the same time. Analysis models show the solution from multiple facets and allow the business analyst
to identify gaps in the models or requirements
Aspects to be
Adaptive Predictive
Tailored
Name part Create and Analyze Models
Scope models and high-level process models are
created and analyzed as part of scoping efforts,
before a project starts or in an early iteration. Models are created and analyzed early during an
Process, rule, data, and interface models are analysis phase. Scope models are typically
Approach created and analyzed as needed to support created first and other models later as product
identifying or elaborating user stories. All models information is elaborated. Models are fairly well
can be refined as needed at any point in any refined and approved before design work begins.
iteration. The entire team might whiteboard the
models together.
Models might not follow formal syntax, might not
Models might follow formal syntax and be
be fully fleshed out, might be informally created as
Deliverables hand-drawn sketches, or can be created and
complete. They are often maintained in a
modeling tool.
stored in a tool.
7.3 DEFINE AND ELABORATE REQUIREMENTS
1. Analysis approach 1. Business rules catalog 1. Requirements and other

2. Analysis models 2. Definition of ready product information
3. Confirmed elicitation results 3. Glossary
4. Relationships and dependencies 4. Product backlog
5. Stakeholder engagement and 5. Requirements management
communication approach tool
6. Story elaboration
7. Story slicing
8. Use case
9. User story
Defining and elaborating requirements includes defining all types of product information, not just requirements. This product
information commonly includes the following:
1. Assumptions and Constraints
2. Dependencies
3. Issues
4. Product Risks
INPUTS
Analysis Approach; included in the analysis approach is a decision about the types of requirements to
be elaborated for the project life cycle and how the requirements and other product information will be
stored. It also describes the requirements attributes that need to be captured during the Define and
Elaborate Requirements process.
Analysis Models; used to derive and elaborate the requirements by helping identify requirements at
any level and by finding gaps, redundancies, and errors in the requirements. Additionally, some analysis
models help define the attributes of requirements. Each analysis model can help derive requirements in
different ways.
Confirmed Elicitation Results; common starting point for identifying draft requirements. However, they
are not the final requirements without additional analysis.
Relationships and Dependencies; although relationships and dependencies help identify requirements
or elaborate attributes, a business analyst might identify additional relationships and dependencies
during this process
Stakeholder Engagement and Communication Approach; defines who will consume the
requirements, the proposed mechanism of communication with those stakeholders, and the plan to
structure and store the requirements. The approach supports efficient interaction of the business analyst
with stakeholders because stakeholder expectations with regard to requirements and communication
are considered and followed, although doing so often requires elicitation to be performed again.
Business Rules Catalog: rule model, is a table of business rules and related attributes, they describe
how to constrain or support behaviors within the operations of the business.
Definition of ready: series of conditions that the entire team agrees to complete before a user story is
considered sufficiently understood so that work can begin to construct it.
It helps the project team know that the user story is sufficiently elaborated and ready to be brought into
an iteration, designed, constructed, and delivered.
Glossary; while defining and elaborating requirements, the business analyst makes sure that all
requirements use terminology as defined in the glossary and keeps the glossary up to date as new
information is identified
Product Backlog; the items can be requirements for the solution to be built, as well as any issues or
defects that have to be resolved from previous iterations. Projects that utilize adaptive approaches use the
product backlog as part of the requirements package.
The product backlog can be stored in a requirements management tool or spreadsheet, or may simply
reside in a list and be tacked to a wall. The items in the product backlog are ranked in order of business
value or importance to the customer and are continuously updated throughout a product’s life cycle or a
project’s duration.
The acronym DEEP describes the characteristics that a product backlog needs to demonstrate:
Detailed appropriately. The level of detail to describe a user story is dependent on the story’s priority. The higher
the priority, the more detailed the story needs to be. A product backlog is detailed appropriately when the
highest priority stories contain the most detail as compared to the lowest-priority items.
Estimated. The items in a product backlog should all be estimated. The higher-priority items should have more
precise estimates than lower-priority items.
Emergent. Product backlogs are a constantly changing list of product backlog items. As inputs change, new
information is discovered, or priorities change, product backlog items might be added, adjusted, removed, or
reprioritized within a product backlog.
Prioritized. All items within a product backlog should be prioritized in a rank-ordered manner, with the highest-
priority items being at the top. As the priority of items changes, the backlog is reordered to reflect those
changes. As items are added or removed, prioritization is adjusted as necessary to accommodate the newly
added items.
Requirements Management Tool: a tool allows requirements and other product information to be
captured and stored in a repository.
often stored in a requirements management tool, including a status, any known attribute values, and
related models. A requirements management tool might serve as the repository for the contents of a
requirements package, depending on the project life cycle approach.
Story Elaboration: the process by which user stories are further detailed with additional information
until they are ready for development. Story elaboration is known as backlog refinement.
Story Slicing: technique used to split epics or user stories from a higher level to a lower level.
An epic, user story, or requirement could be split in a variety of ways, including by type of interface, user
or persona, functionality, data, business rules, constraints, or any combination thereof.
The reason to split stories is that sometimes stories are too big to construct in an iteration
Use Case: a process model that uses textual narrative to describe the system-user interactions to achieve
successful completion of a goal.
This model is frequently used to identify and elaborate requirements, especially when moving from
business requirements to stakeholder requirements or solution requirements.
Use Case Sample

User Story; can be used to map requirements or acceptance criteria back to process models that reflect
overall business user tasks. Acceptance criteria typically capture more details about the users’ needs
OUTPUTS
Requirements and Other Product Information: the requirements themselves. These requirements can
be of any type: business, stakeholder, solution, or transition.
The requirements can be stored in any type of repository, such as a backlog, document, or a
requirements management tool. In addition to requirements, other product information that is
documented as part of this process includes assumptions, dependencies, constraints, issues, and risks.
Aspects to be
Adaptive Predictive
Tailored
User Story Definition, Story Refinement,
Define and Elaborate Requirements or
Name Backlog
Specify Requirements
Refinement, or Elaboration
Requirements are represented as a combination
of user stories and acceptance criteria in a
Significant portions of elicitation might be
product backlog. Although anyone can write a
completed before requirements are specified,
user story, the product owner decides whether
though the two activities will typically be iterative
and where to place the story in the backlog. User
with each other. Individual requirement
stories may be identified in a user story writing
statements, business rules, and use cases are
workshop, so elicitation and user story definition
Approach occur concurrently. User stories are progressively
written based on elicitation results and analysis
of the models. Requirements are typically written
elaborated via backlog refinement sessions. User
at three levels: business, stakeholder, and
stories evolve within a product backlog because
solution requirements. Drafted requirements are
new stories can be added at any time,
reviewed with stakeholders and are refined or
prioritization might change story order, and
elaborated based on the feedback.
just-in-time elaboration will provide additional
details.
Deliverables are created using the principle of
lightweight documentation and stored in a Completed requirements are delivered in a
Deliverables backlog. User stories or product backlog items document or requirements management tool.
need to meet the definition of ready.
7.4 DEFINE ACCEPTANCE CRITERIA
1. Analysis approach 1. Behavior-driven development 1. Acceptance criteria

2. Analysis models 2. Definition of done
3. Requirements and other 3. Story elaboration
product information
4. Solution evaluation approach
Acceptance criteria are the conditions that need to be met before a solution is accepted. They are used to measure whether a
customer is satisfied with the solution built
Acceptance criteria can be created at different levels, including requirement, iteration, release, and product levels
INPUTS
Analysis Approach; includes a decision about how and when in the project life cycle the acceptance
criteria will be defined. The analysis approach describes how acceptance criteria will relate to user
stories, requirements, releases, and solution definitions of acceptance and the level at which they are
written
Analysis Models; can be used to elaborate the requirements or user stories to identify acceptance
criteria
Requirements and Other Product Information; it is used for writing acceptance criteria based on user
stories, requirements, or business objectives. Stakeholders use this input to decide whether to accept or
reject the solution based on how well it met the requirements.
Solution Evaluation Approach: defines what types of metrics will be used to measure the performance
of a solution.
Acceptance criteria are defined to set acceptable ranges on the metrics identified.
Behavior-driven Development: an approach that suggests that the team should begin with
understanding how the user will use a product (its behavior), write tests for that behavior, and then
construct solutions against the tests.
This approach is a continuation of test-driven development, which suggests that writing tests first will
create better products with fewer defects
It includes a commonly accepted syntax to write acceptance criteria for user stories, the given-when-
then format.
The given-when-then format ensures that the business stakeholders should consider the preconditions
of the user in the product, the triggers, and how the product should react in these conditions:
Given <the preconditions>,
when <the user does something within the product>,
then <the product reaction>.
Definition of Done: series of conditions that the entire team agrees to complete before an item is
considered sufficiently developed to be accepted by the business stakeholders
Story Elaboration; in adaptive approaches, user stories are commonly written at a higher level of detail
than functional and nonfunctional requirements, so story elaboration is the technique used to add the
extra details for each story so that development teams have enough information to build the solution.
Design information and customer decisions are only added to the user story “just in time” for
development to work on the user story.
OUTPUTS
Acceptance Criteria: are concrete and demonstrable conditions about an item that need to be met for
the business stakeholders or customers to accept the item.
This output can take the form of lists of acceptance criteria for each user story in an adaptive approach,
or may be a list of higher-level acceptance criteria for a release or solution in a predictive approach.
Regardless of the level at which they are defined, the acceptance criteria should align to the
requirements and other product information because acceptance testing or evaluation of the solution
will be based on the acceptance criteria. The definition of done is part of this output
Aspects to be
Adaptive Predictive
Tailored
Define Acceptance Criteria, Backlog
Define Acceptance Criteria or Define
Name Refinement,
Evaluation Metrics
or Elaboration
Acceptance criteria are defined and might map
Written as part of user stories, typically with more to requirements, business objectives, or other
than one acceptance criterion per user story. success metrics. Acceptance criteria at the
Often used to define the details from which teams requirement level are defined together with
develop and test solutions and are often at the requirements or after requirements are defined.
Approach level of solution requirements. They are created, They are used to help refine requirements by
reviewed, and refined throughout all iterations of pointing out any lack of clarity. Acceptance criteria
a project for each user story, just in time for defined at the release or product level are defined
development. early in a project once the goals and objectives
are understood.
Deliverables Acceptance criteria are defined and sometimes documented in a tool.

7.5 VERIFY REQUIREMENTS
1. Analysis approach 1. INVEST 1. Verified requirements and other

2. Business analysis organizational 2. Peer reviews product information
standards
3. Compliance or regulatory
standards
4. Requirements and other
product information
Verification is the process of reviewing the requirements and other product information for errors, conflicts, and adherence to
quality standards. Verification also involves evaluating whether requirements and other product information comply with a
regulation, specification, or imposed condition.
Verification can be performed on product information at the portfolio, program, or project levels. It can be conducted on a
single requirement, a single model, or a set of product information
INPUTS
Analysis Approach; includes a decision about when verification of the product information will be
performed. It also describes the verification techniques and which, if any, standards should be used.
Business Analysis Organizational Standards; describe any expected quality characteristics, formatting
rules, syntax rules, and requirements structure imposed by the organization on all business analysis
deliverables
Compliance or Regulatory Standards: imposed by external organizations, commonly for reasons
related to security, protecting personal information, legal considerations, or safety reasons.
Most often, they are government or industry regulations. Some standards take the form of what the
documentation for a project should include, while others may list actual requirements that the project
has to include in its requirements set.
Requirements and Other Product Information; If the reviewer is someone other than the author, the
reviewer provides feedback to the author about any changes that need to be made to the requirements
and other product information to make the information clearer or so that it better conforms to the
chosen standards
INVEST: describes the characteristics that user stories need to demonstrate to be considered “good”
and “ready” for development in adaptive approaches.
Independent. The characteristic that breaks as many dependencies between user stories as possible so that any user
story can be built by itself in any order by the development team.
Negotiable. The characteristic in adaptive methodologies that ensures that too much information is not captured up
front, because all user stories and the details surrounding them should be negotiable between the development team
and the business stakeholders until a story is accepted for development.
Valuable. A characteristic where each story has value to the business or the customer and the backlog is ranked
based on that value.
Estimable. The characteristic that balances against the negotiable characteristic to ensure that user stories have
enough detail for the development team to provide a rough estimate of size.
Small. In the adaptive sense, small means that the story is small enough for the development team to complete it
within a single time-boxed iteration.
Testable. The characteristic that determines whether a story can be finitely tested by a test team and if the customer
understands how to accept the final requirement as done. It is usually written in the form of acceptance criteria.
Peer Reviews: involve one or more coworkers reviewing the work completed by the business analyst.
Commonly, the peer who performs the review is another business analyst, team lead, or quality control
team member.
Reviewers focus on reviewing the logic and readability of the requirements, along with adherence to
internal organizational standards for quality characteristics, format, and syntax.
Three common types of peer reviews, in order of least to most formal, are as follows:
Peer desk check. An informal peer review completed by one or multiple peers simultaneously to look over the
materials. Desk checking is a way to review any logic in a set of requirements, analysis models, or other product
information, and often involves working through an example to check logic. A peer reviewer walks through an
analysis model or set of requirements with an objective eye to catch any issues or inconsistencies.
Walkthrough. A peer review in which the author of the materials walks the peer reviewers through the authored
information. These reviews are often held using an elicitation workshop technique. Feedback is typically given
verbally during the session.
Inspection. A formal and rigorous form of review in which practitioners close to the work (usually other business
analysts, developers, test team members, or quality team members) inspect the work for completeness, consistency,
and conformance to internal and external standards, often referring to a checklist. The inspector uses the checklist
and the inspection process to review a set of requirements and provide feedback to the authoring business analyst.
OUTPUTS
Verified Requirements and Other Product Information: include product information that has been
evaluated to ensure that it is free from errors and addresses the quality standards to which the
information will be held.
Verified requirements are not a guarantee that those same requirements address the business needs.
The requirements also have to be validated, prioritized, and approved.
Aspects to be
Adaptive Predictive
Tailored
User Story Reviews, Story Elaboration, or
Verify Requirements or Requirements
Name Backlog
Reviews
Refinement
User stories and acceptance criteria are checked Requirements and analysis models are often
against the INVEST criteria and any internal or formally verified and completed after the
external standards prior to pulling a user story into requirements have been defined and elaborated.
Approach an iteration. Models can also be verified. The Requirements and models can be validated
process is performed incrementally, just in time for before, after, or while they are verified.
each user story to be built. Requirements are verified before being approved.
Reviewed requirements documents with feedback
Deliverables Refined user stories are updated in the backlog.
and sometimes audit trails of the documents.
7.6 VALIDATE REQUIREMENTS
1. Acceptance criteria 1. Delphi 1. Validated requirements and

2. Analysis approach 2. Goal model and business other product information
3. Business goals and objectives objectives model
4. Requirements and other 3. Traceability matrix
product information 4. Walkthroughs
Validation is the process of ensuring that all requirements and other product information accurately reflect the intent of the
stakeholders and that each requirement aligns to one or more business requirements
Validation can be conducted on a single requirement, a single model, or on a set of product information.
INPUTS
Acceptance Criteria; used to ensure that all requirements and other product information are mapped
to the agreed-upon acceptance criteria. If not, the user story, iteration, release, or solution is not on
track to be accepted.
Analysis Approach; includes a decision about when validation of the product information will be
performed. It also describes which validation techniques are appropriate to use.
Business Goals and Objectives; ensuring that all requirements trace back to the business goals and
objectives so what is proposed to be built will actually meet the stated goals and objectives.
Requirements and Other Product Information; often, this input will change as a result of validation
because requirements or product information will be discovered to be missing, unnecessary, or incorrect
Delphi: a consensus-building method that consolidates anonymous input from subject matter experts
(SMEs) using rounds of voting
This method reduces peer pressure or groupthink in the validation process and avoids having the team
give in to a voice of authority with which they might disagree. Delphi can be used on requirements or
any other product information, such as features, user stories, and acceptance criteria
Goal Model and Business Objectives Model; either model can be helpful for mapping requirements or
user stories through features or other models back to business objectives to ensure that requirements
are in alignment with business objectives.
Traceability Matrix: a grid that allows for linkages between objects. A traceability matrix can be used to
trace requirements to other types of requirements in the hierarchy
Used to trace the requirements to analysis models and ultimately to the business objectives that each
requirement supports. This analysis ensures that each business objective has coverage by the
requirements and that each requirement traces directly back to support a business objective.
Walkthroughs: holding a meeting or meetings to review the requirements as a group, to ensure that
there is a common understanding of the requirements and whether they are needed
Used to review the requirements with the stakeholders and to receive confirmation that the
requirements as stated are valid.
OUTPUTS
Validated Requirements and Other Product Information: include product information that the
stakeholders agree meets the business goals and objectives.
Validated requirements are not a guarantee that those same requirements are well written and address
the standards to which the project will be held. The requirements also have to be verified, prioritized,
and approved.
Aspects to be
Adaptive Predictive
Tailored
User Story Reviews, Story Elaboration, or
Validate Requirements or
Name Backlog
Requirements Reviews
Refinement
User stories and acceptance criteria are reviewed Requirements and analysis models are often
in real time with the business stakeholders or formally validated. Walkthroughs can be a formal
during backlog refinement and traced back to the process and are completed after the
Approach business goals. Models are also validated. This is a requirements have been defined and elaborated.
continuous activity, because any user stories that Requirements can be validated before, after, or
are no longer valid should be removed from the while they are verified. Requirements are often
product backlog immediately. validated before being approved.
Deliverables Refined user stories are updated in the backlog. Traced requirements.
7.7 PRIORITIZE REQUIREMENTS AND OTHER
PRODUCT INFORMATION
1. Analysis approach 1. Backlog management 1. Prioritized requirements and

2. Business goals and objectives 2. Goal model and business other product information
3. Change requests objectives model
4. Relationships and dependencies 3. Iteration planning
5. Requirements and other 4. Kanban board
product information 5. Prioritization schemes
6. Story mapping
7. Traceability matrix
it is necessary for accountable stakeholders who have authority to prioritize requirements to be involved in this process
The project life cycle influences the prioritization process and often dictates the frequency, timing, and techniques for
performing prioritization
INPUTS
Analysis Approach; includes a decision about the approach for prioritization, including which
techniques will be used, when prioritization is performed, and who will participate in and make
prioritization decisions.
Business Goals and Objectives; The desired outcomes specified by the business objectives are the
primary consideration in prioritizing which requirements and related work should be completed first. A
key purpose of the prioritization process is ensuring that what the team builds actually meets the
business goals and objectives.
Change Requests: appeals to make a change to a requirement or other suggestions for changes to
product information that are raised by the business stakeholders or project team after a set of
requirements is baselined.
Change requests are prioritized along with other work, including any undeveloped requirements.
Sometimes a change request is of higher priority than existing work. Some change requests may require
items to be removed from scope, to accommodate the change.
Relationships and Dependencies; it can affect prioritization of requirements depending on others
Requirements and Other Product Information; shows the accumulated throughout the portfolio,
program, or project comprise the information prioritized.
Backlog Management: the process by which the owner of the backlog, commonly a product owner,
assists in keeping the backlog up to date in terms of prioritization and latest requirements.
Goal Model and Business Objectives Model; either model can be used as a tool to help prioritize the
requirements according to how much they support or achieve the objectives
Iteration Planning: adaptive approaches, iteration planning or sprint planning is the activity used to
identify the subset of product backlog items that the product development team will work on for the
current iteration or sprint.
The entire team collaborates just before or at the beginning of the iteration to select the backlog items
that should be part of an iteration backlog. The business analysis responsibilities entail choosing items
for the iteration backlog that are sufficiently elaborated upon and most important in terms of delivering
business value.
Knaban Board: used in adaptive approaches to track work that is in progress by the project team. It is a
visual representation of what work is in progress, whereas the product backlog is the prioritized list of all
possible work.
Kanban Board Sample

Prioritization Schemes: different methods used to prioritize portfolio components, programs, projects,
requirements, features, or any other product information.
The following are some commonly used schemes:
Buy A Feature: used to enable a group of stakeholders to agree on prioritization by providing each stakeholder with
an amount of pretend money to buy his or her choice of features, splitting the money received across features,
however desired. The features are prioritized by counting the total money spent per feature by all stakeholders.
Delphi; This method is intended to reduce peer pressure or groupthink in the prioritization process or to avoid the
team giving in to a voice of authority with whom they may disagree
Minimum Viable Product (MVP): A prioritization mechanism used to define the scope of the first release of a
solution to customers by identifying the fewest number of features or requirements that would constitute a solution
from which the customer would obtain value
MoSCoW: a technique that categorizes each requirement into one of the following groups:
▬ Must have (fundamental to solution success),
▬ Should have (important, but the solution’s success does not rely on the requirement),
▬ Could have (can easily be left out without impacting the solution), or
▬ Won’t have (not delivered this time around).
Multivoting: method also called dot voting because it can be performed by providing stakeholders with a prescribed
number of colored dots and allowing them to vote by placing their dots on the requirements that they feel are the
most important. All votes are aggregated and requirements are ranked by the number of dots/votes received.
Purpose Alignment Model; to identify each option by considering how mission critical it is and how much
competitive advantage each will provide to the organization. While this technique is primarily intended as a basis for
making strategic or high-level product decisions, some organizations also use it to analyze and facilitate discussions
about product requirements and the value each provides, which, in turn, becomes a springboard for prioritization
discussions about product features and requirements.
Timeboxing: an estimation or planning technique that can be used during prioritization by setting a strict time limit
and prioritizing only the work that the team can complete in that duration of time. Timeboxing is usually used in
conjunction with a second prioritization scheme to understand the highest-prioritized requirements to pull into the
time-box.
Weighted Ranking: a method that first requires decision criteria to be identified and weighted. Then each item is
rated by scoring how well the option meets the criteria independent of other options. Ratings are multiplied by the
weights and summed to arrive at the score for each item and the overall rankings.
Weighted shortest job first (WSJF): A method used primarily in adaptive frameworks to rank user stories based on
more dimensions than just business value and effort. WSJF works by having business value, time criticality, risk
reduction or opportunity enablement, and effort all sized using something similar to a Fibonacci sequence used in
estimation poker. A formula is used to calculate a weighted value for each user story:
WSJF = [business value + time criticality + (risk reduction/opportunity enablement)] / effort
Story Mapping; although it can be used as a prioritization technique by itself, other prioritization
techniques can be used to help prioritize the user stories in the story map. This technique is primarily
used when following an adaptive delivery approach.
Releases can be shown on a story map as horizontal lines, dividing and grouping functionality based on
the capacity of the development team and the release dates. Each horizontal grouping is a release, and
each vertical grouping can be thought of as a functional grouping.
Traceability Matrix; can be used to help prioritize requirements using the business objectives to which
they are traced. If the business objectives are quantified and ranked accordingly, then the requirements
that trace to the highest-value objectives might be the highest-ranked requirements. Any requirements
that are not traced to the business objectives are out of scope
OUTPUTS
Prioritized Requirements and Other Product Information: a representation of which requirements

and other product information the stakeholders agree are most important to address first to achieve the
business goals and objectives.
The prioritization output can take the form of a backlog ordered by business value and risk in adaptive
approaches or a prioritization attribute set on each requirement in predictive approaches.
Prioritization also indicates which items are of low priority and might be reasonable to cut from scope if
change requests come in and are prioritized higher or if the team runs out of time or budget for a
release.
When requirements and other product information are used as input into other processes, they might
include product information that has been prioritized.
Aspects to be
Adaptive Predictive
Tailored
Prioritize Requirements and Other
Backlog Management, Prioritize Backlog, or
Name Product
Backlog Ranking
Information
Features or user stories are the most commonly Features, requirements, and change requests are
prioritized product information, but any items in prioritized commonly after they are verified and
the backlog can be prioritized. Product information validated and either before or after they are
is continuously prioritized and reprioritized in the approved. Prioritization results are reflected on
product backlog by the product owner or the each requirement in the requirements set.
Approach business analyst. The product backlog is a living Prioritization occurs before any solution
prioritized list of requirements, so it needs to construction begins. Priorities may still shift
always reflect the top priorities of the business. throughout the project, but incorporating such
Prioritization techniques are used for each changes is more difficult than just reordering
iteration to determine the features to be provided things, often requiring a change control process
in the next release of the solution. to be executed.
Each requirement in the requirements set will
Prioritized backlog, ordered by business value or a
Deliverables combination of business value and business risk.
have a priority based on whatever prioritization
scheme was chosen.
7.8 IDENTIFY AND ANALYZE PRODUCT RISKS
1. Analysis approach 1. Context diagram 1. Prioritized requirements and
2. Business goals and objectives 2. Ecosystem map other product information
3. Enterprise environmental 3. Elicitation techniques
factors 4. Estimation techniques
4. Product scope 5. Organizational chart
5. Requirements and other 6. Process flows
product information 7. Product backlog
8. Risk burndown chart
9. Risk register
10. Root cause and opportunity
analysis
11. SWOT analysis
Identifying and analyzing product risks includes the following activities:

1. Identifying Product Risks
2. Performing Qualitative Risk Analysis
3. Performing Quantitative Risk Analysis
4. Planning Risk Responses
5. Implementing Risk Responses
6. Monitoring Risks
INPUTS
Analysis Approach; shows a decision about how to conduct risk analysis, including details regarding the
product risk management process, the risk categories, and how risks will be documented.
Business Goals and Objectives; product risks are evaluated and rated on whether and how much they
may impact the business goals and objectives. Evaluating assumptions that were made in defining
business goals and objectives might also lead to identifying additional risks.
Product Scope; product risks are evaluated and rated on whether and how they may impact the
product represented by the product scope statement
Requirements and Other Product Information; product information can be evaluated to identify
product risks. For instance, assessing assumptions, constraints, dependencies, and the requirements may
help uncover product risk factors.
Product risk responses may trigger modifications or additions to requirements and other product
information.
Context Diagram; it clearly depicts the in-scope systems and any inputs or outputs, including the
systems or actors providing or receiving them. These models can be used to identify product risks or
failure points by analyzing the interfaces.
Ecosystem Map; may be used to identify product risks or potential failure points, through analyzing the
interfaces and objects passed between the systems.
Elicitation Techniques; product risks are uncovered through elicitation; thus, any of the elicitation
techniques can be used to identify and analyze product risks
Estimation Techniques; various estimation techniques can be used to quantify the probability and
impact of product risks
Organizational Chart; can be used to identify risks related to stakeholder groups
Process Flows; used to identify product risks or potential failure points by analyzing process steps,
decision points, and handoffs between different actors in a process.
Product Backlog; when needed, tasks called spikes or risk spikes can be added to the product backlog
to evaluate risks.
Risk Burndown Chart: a burndown chart used to show the status of risks across iterations
The sum of exposures (probability multiplied by impact) across all product risks is mapped for each
iteration.
Risk Register: a tool used to support analysis of product risks. Product risks are logged with
corresponding details, which may include the following:
Risk Description
Risk Owner
Impact Rating
Probability Rating
Exposure
Risk Response
Etc.
Root Cause and Opportunity Analysis; can be used to develop response plans to proactively address
negative product risks or take advantage of potential opportunities
SWOT Analysis; can be used to identify potential product risks in the form of positive risks
(opportunities) or negative risks (threats).
OUTPUTS
Product Risk Analysis: includes the consolidated results from identifying and analyzing product risks
It may consist of:
Identified product risks,
List of potential responses,
Relative rating or priority list of risks,
Symptoms and warning signs,
Risks requiring responses in the near term,
Risks for additional analysis and response,
Trends in qualitative analysis results,
Total risk exposure, and
Watch list of low-priority risks.
Aspects to be
Adaptive Predictive
Tailored
Name Not a formally named process Identify and Analyze Product Risks
Risks are discussed and addressed in iteration 0,
Integrated with portfolio, program, or project risk
iteration planning, and/or daily stand-ups and
management processes that are performed
considered when determining the value of backlog
throughout the portfolio, program, or project,
Approach items. Assumptions, constraints, dependencies,
respectively. Assumptions, constraints,
issues, and risks may be discussed at the same
dependencies, issues, and risks may be
time. Teams focus on short iterations that
discussed at the same time.
minimize risk.
Robust risk register. Sometimes assumptions,
Deliverables Risk spikes are added to the backlog. constraints, dependencies, issues, and risks are
combined into a single register.
7.9 ASSESS PRODUCT DESIGN OPTIONS
1. Business goals and objectives 1. Affinity diagram 1. Viable product design options
2. Enterprise and business 2. Brainstorming
architectures 3. Competitive analysis
3. Prioritized requirements and 4. Focus groups
other product information 5. Product backlog
6. Real options
7. Vendor assessment
This process entails understanding which design options are available and analyzing the details about how those designs
would evolve into a solution
Design discussions need to take place before construction begins for any given solution or component of a solution, even if it
is only a small piece of the solution. Avoiding these discussions may result in missed objectives or products that are
unintuitive to use. Also, product development might take more time if the teams are trying to make up design choices as they
go.
INPUTS
Business Goals and Objectives; designs need to be aimed at achieving these goals and objectives.
Poorly designed solutions that meet the requirements can keep the solution from achieving the desired
goals and objectives.
Enterprise and Business Architectures; used to ensure that the proposed designs can operate within
the existing architectures or to understand how those architectures might change with proposed
designs. The design options might be constrained by either architecture.
Prioritized Requirements and Other Product Information; Prioritized requirements represent the
stakeholders’ agreement about which requirements need to be addressed first in the solution and
therefore also represent which requirements are most important to account for in the designs.
Affinity Diagram; can be used to help identify design options by organizing user stories, features, or
requirements, resulting with grouping of similar designs and aiding in the decision process when trying
to make a choice from among different design options. It can also facilitate brainstorming new design
ideas.
Brainstorming; used to identify design options and any risks associated with them.
Competitive Analysis; used when identifying and comparing design options to create an advantage for
the product in the marketplace as compared to competitors. It is useful to understand if a proposed
design is far more than what a competitor offers
Focus Groups; can be used to solicit attitudes and ideas about different design options.
Product Backlog; product backlog items need to be factored into the design, even if the design is
lightweight and not formally documented
Real Options; When assessing product design options, delaying a recommendation about a possible
design provides time for more information to be discovered and analyzed, answering unknowns and
thereby reducing the number of uncertainties that would be present if the design choice had been made
earlier.
It can also eliminates design options that are not feasible by considering the business objectives and
goals, expected costs, and risks
Vendor Assessment: vendors may provide the solution that best meets the requirements
When assessing product design options, relevant vendors and their products are evaluated to
understand the viability, strengths, weaknesses, and risks of each vendor solution.
Performing a vendor assessment entails identifying a set of criteria by which vendors and their products
will be evaluated. The criteria used to make this assessment might be a set of requirements, user stories,
or features, and can be prioritized or weighted.
OUTPUTS
Viable Product Design Options: representations of how the solution could be constructed
Viable product design options are those that have been reviewed by stakeholders to ensure that they
achieve the business goals and objectives and are feasible. Viable product design options are presented
with the pros and cons of each option.
Once a design is selected, construction of the solution or component of the solution can begin.
Aspects to be
Adaptive Predictive
Tailored
Name Elaboration, Sizing, or Spikes Identify and Analyze Product Risks
User stories and acceptance criteria are the basis
for any design work. Design is performed iteratively
as part of elaboration, sizing, or as the solution is
developed. Typically, design is done just in time Requirements are completed and are the basis
Approach before development, though adaptive life cycles for any design work, and design choices are fed to
often do some initial overarching design early in a the team responsible for building the solution.
project to minimize major redesign efforts. Spikes
are tasks used to evaluate multiple design options
against one another.
Designs are sketches or ideas and often are not Formally specified or modeled designs,
Deliverables formally documented. completed in tools or documents.
TRACEABILITY AND
MONITORING
TRACEABILITY AND MONITORING OVERVIEW
8.1 Determine Traceability and Monitoring Approach
8.2 Establish Relationships and Dependencies
8.3 Select and Approve Requirements
8.4 Manage Changes to Requirements and Other Product Information
8.1 DETERMINE TRACEABILITY AND MONITORING
APPROACH
1. Compliance or regulatory 1. Retrospectives and lessons 1. Traceability and monitoring

standards learned approach
2. Configuration management
standards
3. Product scope
traceability and monitoring approach defines the traceability and change management processes for the portfolio, program,
project, or product. Each should be structured at a level of formality that is sufficient to meet the needs of the portfolio,
program, project, and product.
INPUTS
Compliance and Regulatory Standards; the traceability and monitoring approach needs to adhere to
compliance and regulatory standards, the tailoring options may be constrained. Compliance and
regulatory standards often mandate more formal approaches to traceability and monitoring.
Configuration Management Standards: a collection of formal documented processes, templates, and
documentation used to apply governance to changes to the solution or subcomponent under
development
It ensures that the requirements and requirements-related product information are stored where they
can be easily accessed by project stakeholders, safeguarded from loss, and where access to previous
versions is available, when needed according to the standards.
Product Scope; used to understand the level of product complexity used to determine an appropriate
size for the traceability and change management approach.
Retrospectives and Lessons Learned; provide past performance information to the product team for
use in improving future performance and, ultimately, the end product
When determining how best to approach traceability and monitoring, product teams can rely upon
acquired knowledge and learning to determine which traceability and monitoring approach to follow.
OUTPUTS
Traceability and Monitoring Approach: defines how traceability and change management activities
will be performed throughout the portfolio, program, or project.
The traceability components of the approach include types of objects to trace, types of relationships, the
level of tracing detail required, and information about where tracing information will be tracked.
The monitoring components of the approach include how changes are proposed and reviewed, how
decisions are documented and communicated, and how changes are made to existing product
information.
Aspects to be
Adaptive Predictive
Tailored
Determine Traceability and Monitoring
Name Not a formally named process
Approach
A high-level traceability and monitoring approach
May be planned at a high level in iteration 0. is defined early, during planning. The traceability
Tracing and managing changes to product and monitoring approach is refined throughout
information are often not considered, as these the portfolio, program or project. Often, large
processes are already built into adaptive components of product information and
Approach approaches. Traceability performed via story deliverables are traced. A change management
splitting or story mapping and change process often exists, but the level of formality is
management is performed via backlog dependent on multiple factors, including
management. organizational maturity, size and the complexity
of the initiative.
Detailed traceability and monitoring approach
might reside in a business analysis plan.
8.2 ESTABLISH RELATIONSHIPS AND DEPENDENCIES
1. Product scope 1. Feature model 1. Relationships and dependencies

2. Requirements and other 2. Requirements management
product information tool
3. Traceability and monitoring 3. Story mapping
approach 4. Story slicing
Because requirements are often related to other requirements, sometimes a requirement is not able to be satisfied in a
solution without including the other requirements to which it is related. Some examples of relationships between
requirements are as follows:
1. Subset
2. Implementation Dependency
3. Benefit/Value Dependency
INPUTS
Product Scope; product information is traced to the features and functions that make up the definition
of product scope.
Requirements and Other Product Information; relationships and dependencies are established
between the requirements and other product information resulting from elicitation and analysis.
Traceability and Monitoring Approach; defines the decisions made by the team about how
traceability will be performed on the portfolio, program, or project.
The product team will monitor the approach as it is followed to ensure that the traceability work is
adding value. Too much traceability will become time-consuming to maintain, and if the team abandons
the traceability work, information will become outdated.
While preplanning is performed to ensure that the right traceability approach is established for the
portfolio, program, or project, the traceability and monitoring approach can be revised as the team
assesses the value throughout the course of its work
Feature Model; shows relationships between features and which features are subfeatures of other ones.
The feature model helps teams establish and communicate relationships between different features.
Requirements Management Tool: a tool allow requirements and other product information to be
captured and stored in a repository. Traceability support is a common feature in most requirements
management tools today.
Story Mapping; User stories may be grouped by different categories such as functionality, themes, or
application. Story mapping can be used to establish relationships between user stories to iterations and
the higher-level categories
Story Slicing; it is a means of establishing relationships between requirements as lower-level
requirements or user stories are subsets of higher-level requirements or epics.
Traceability Matrix; it can support linkages among many different types of objects, providing a
mechanism for tracking product information through the project and product life cycles. A traceability
matrix can be used to establish relationships among product information, deliverables, and project work
to ensure that each relates back to business objectives
OUTPUTS
Relationships and Dependencies: are the linkages established among objects, such as components of
product information, deliverables, and project work.
Relationships and dependencies are established to help ensure that product information adds business
value and meets customer expectations, manages scope, decreases the probability of missing
requirements, performs impact analysis, and makes release decisions
Aspects to be
Adaptive Predictive
Tailored
Establish Relationships and
Name Backlog Refinement
Dependencies or Trace Requirements
Typically establishes linkages between user
stories and acceptance criteria. Might trace to Minimal to extensive tracing, bidirectional
objectives. Epics or user stories may be traced to between all components of product information,
features and acceptance tests. Any components and deliverables that may contain product
of product information might trace forward to information. Established throughout the product
Approach design and test and ultimately to the solution. life cycle. As more product information is defined,
Performed iteratively via story slicing or story more detailed traceability is performed.
mapping as new items are added to the product Performed after an analysis phase of a project to
backlog. May be forms of direct tracing such as trace forward to design and test and ultimately,
attaching a visual model to a story or linking user the final solution.
stories and acceptance criteria.
Feature model, story map, interaction matrix, or Small to large traceability matrices. Regulatory
linked product information like stories and environments often dictate formal traceability.
Deliverables acceptance criteria that may be stored in a Traceability information may be stored in a
requirements management tool. requirements management tool.
8.3 SELECT AND APPROVE REQUIREMENTS
1. Product scope 1. Backlog management 1. Approved requirements

2. Relationships and dependencies 2. Collaborative games
3. Stakeholder engagement and 3. Definition of ready
communication approach 4. Delphi
4. Validated requirements and 5. Facilitated workshops
other product information 6. Force field analysis
5. Verified requirements and other 7. Group decision-making
product information techniques
8. Iteration planning
9. Prioritization schemes
10. Requirements management
tool
11. Story mapping
The key benefit of this process is that it provides authorization to consider how and when to build all or part of a solution to
develop or modify a product.
Organizations and projects vary in how requirements are approved. Some organizations require a formal sign-off on a
requirements package, such as a business requirements document. In other organizations or for specific types of projects, the
approval of requirements may be informal, requiring only verbal approval
INPUTS
Product Scope; requirements approval is performed to confirm with stakeholders that the defined
product information is correct and within the established scope parameters
Relationships and Dependencies; indicate which requirements may need to be selected and approved
together
Stakeholder Engagement and Communication Approach; it contains the decisions about the role
responsibilities and authority levels governing the requirements approval process. The approach
identifies who has responsibility for reviewing, approving, rejecting, and proposing changes to
requirements.
Validated Requirements and Other Product Information
Verified Requirements and Other Product Information
Commonly the requirements and supporting product information are both verified and validated prior
to being presented to stakeholders for review and approval.
Backlog Management; the prioritization of the backlog can be interpreted as approval.

The list is ranked in order of business value or importance to the customer and sized by the
development team so that the team can work on the highest-value items that it can deliver over the
specified duration.
Collaborative Games; can be used to work through requirements-related conflicts and help teams work
toward consensus on requirements.
Definition of Ready; can be used in place of approval in adaptive life cycles to help the project team
know that the user story is sufficiently elaborated and ready to be brought into an iteration for the
development team to work on.
Delphi; can be used to gain consensus on anything, including requirements approval, requirements
validity, estimation, prioritization, and design option preferences
Facilitated Workshops; can be used to bring product teams together to select and approve
requirements, or resolve requirements conflicts that are hindering the team from reaching consensus
Force Field Analysis: a decision-making technique that can be used to help product teams analyze
whether there is sufficient support to pursue a change.
A description of the change is placed in the middle of the model. The team identifies the forces for or
against the proposed change. Forces that support the change are listed on the left and the forces that
are impediments are listed on the right.
Group Decision-making Techniques; can be used in conjunction with other techniques to solve
requirements-related conflicts.
Iteration Planning; Because the results of iteration planning provide the backlog items that will be
considered the planned work for the current or next iteration, these items can be interpreted as
approved
Prioritization Schemes; it can also be used to resolve requirements-related conflicts
Requirements Management Tool; often include workflow functionality to facilitate review and
approval processes
Story Mapping; can be used to perform release allocation in which features or solution components are
assigned to different product releases.
OUTPUTS
Approved Requirements: are an indication that those with the authority to approve requirements have
agreed that the requirements as stated are what the product development team should build.
On projects using an adaptive life cycle, approved requirements can be represented by a prioritized
backlog ready for development or stories chosen from the product backlog as the planned work for the
next or subsequent iteration
On predictive projects, requirements, once reviewed, are approved by decision makers and the approved
set of requirements establishes the requirements baseline. The process to approve requirements may
involve written approval or sign-off or could involve verbal acceptance. During planning, the product
team determines the approval process, including the roles that should participate.
Aspects to be
Adaptive Predictive
Tailored
Name Backlog Refinement or Iteration Planning Select and Approve Requirements
The product owner’s prioritization of the backlog Approval is obtained after verification and
can be interpreted as approval. Definition of validation, but before design. May require sign-off
ready may also be used in place of approval. of a document—for example, a requirements
Prioritization of backlog occurs continuously until package, such as a business requirements
Approach a set of items is moved into an iteration. document (BRD). In some cases, verbal approval
Requirements management tools may be used to may suffice. A requirements management tool
create and manage product and iteration may be used to facilitate review and approval
backlogs. processes.
Prioritized backlog ready for development, or
Baselined requirements package and approvals
decision on content to be built in an iteration or
Deliverables sprint, or designation of what gets pulled next
may be stored in a repository, such as a
requirements management tool.
from “to do” to “doing” on a kanban board.
8.4 MANAGE CHANGES TO REQUIREMENTS AND OTHER
PRODUCT INFORMATION
1. Approved requirements 1. Backlog management 1. Recommended changes to

2. Business goals and objectives 2. Change control tools requirements and other product
3. Change requests 3. Group decision-making information
4. Product scope techniques
5. Relationships and dependencies 4. Impact analysis
6. Traceability and monitoring 5. Requirements management
approach tool
The key benefit of a requirements change process is that it provides a process to manage changes to approved requirements
while minimizing product and project risks associated with uncontrolled and unapproved change.
Negative impacts to the product and project often arise from making changes without taking into consideration any
dependencies, and how the change will affect the overall product and project, including expected business value.
8.4 MANAGE CHANGES TO REQUIREMENTS AND OTHER
PRODUCT INFORMATION
The following courses of actions are possible after the proposed change is evaluated:
• Change approved. Necessary updates to the impacted business analysis deliverables are made.
• Change deferred. The decision to defer making the change is documented, along with a rationale for the decision.
• Change rejected. The decision to reject the proposed change is documented, along with the rationale for the decision.
• More information required. Despite best efforts to ensure that the impact analysis is thoroughly constructed, sometimes
the change control board (CCB) or approval team requests more information. Conditions in the business may have
changed since the project was first approved, or the CCB may now be considering different solutions or working from new
data that were unavailable previously.
INPUTS
Approved Requirements; are requirements that are verified, validated, and deemed an accurate
representation of what the product development team should build. In predictive life cycles, change
requests are evaluated against the approved requirements to conduct an impact analysis.
Business Goals and Objectives; new or revised requirements or product information is evaluated to
ensure that these requirements are aligned with and supporting the attainment of the stated goals and
objectives.
Change Requests
Product Scope; when a proposed change is determined to be outside of the defined product scope,
decision makers will need to consider whether a modification to the product scope is viable.
Relationships and Dependencies; used to identify other impacted backlog items to size up the impact
of making a change
Traceability and Monitoring Approach; includes information on who can propose and approve
changes and how those changes are proposed and evaluated.
Backlog Management; proposed changes or new stories are added to the bottom of the backlog,
where they sit until the next time the backlog is reprioritized.
Change Control Tools: manual or automated and are used to manage change requests and the
resulting decisions, two examples are:
Configuration management system (CMS). It provides a process for verifying this conformance, documenting
changes, and reporting the status of each change throughout the project life cycle. It includes documentation, a
tracking process, and defined approval levels necessary for authorizing changes. It enables managing changes to
aspects of a solution in the context of the entire product, as well as the context of other products on which it
depends or that depend upon it.
Version control system (VCS). A VCS tracks the history of revisions of any type of work product. A VCS is like a
baseline in that the original work product is established, and changes to that work product are tracked. A VCS falls
under the umbrella of a CMS and is one of the many functions that comprise configuration management.
Group Decision-making Techniques; can be used in conjunction with other techniques to decide
whether proposed changes should be acted on
Impact Analysis: a technique used to evaluate a change in relation to how it will affect related elements.
When a change to product information is proposed, an impact analysis is performed to evaluate the
proposed change in relation to how it will affect components of the portfolio, program, project, and
product, including requirements and other product information
Requirements Management Tool; often include functionality to maintain audit trails and perform
version control to assist with change control. Workflow functionality can facilitate review and approval
processes for changes.
Traceability Matrix; The affected relationships are easily recognized and can be used to quickly and
roughly quantify the size and complexity of the change
OUTPUTS
Recommended Changes to Requirements and Other Product Information: describe the course of
action that is proposed after analyzing all the impacts associated with making a proposed change,
including impacts to product and project scope, product usage, value, risk, schedule, and cost.
The possible courses of action include approving the change, deferring the change, rejecting the
change, or requesting additional information before making a decision about the change.
Aspects to be
Adaptive Predictive
Tailored
Manage Changes to Requirements and
Name Backlog Refinement Other Product Information or Change
Control
No formal change management procedures. Change control begins after requirements are
Change is expected and embraced. Change can approved. Formalized change management
occur anytime, outside an iteration. Additional process is followed, including roles and process
Approach details can be added to stories within an iteration steps. New product information is captured in a
if the team agrees to it. New stories are added to change request. Change is often treated like a
the product backlog and change is prioritized mini-project, with elicitation, analysis, assessment
through refining the backlog or iteration planning. of value, and requirements approval.
Scaled impact analysis is conducted. Impact analysis with recommended course of
Deliverables Determination where the change should be action. Revised requirements documentation and
prioritized within the backlog. updated or new models.
SOLUTION EVALUATION
SOLUTION EVALUATION OVERVIEW
9.1 Evaluation Solution Performance
9.2 Determine Solution Evaluation Approach
9.3 Evaluate Acceptance Results and Address Defects
9.4 Obtain Solution Acceptance for Release
9.1 EVALUATE SOLUTION PERFORMANCE
1. Business case 1. Cost-benefit analysis 1. Assessment of business value

2. Business goals and objectives 2. Elicitation techniques
3. Evaluated acceptance results 3. Product portfolio matrix
4. Performance data 4. Prioritization schemes
5. Solution evaluation approach 5. Root cause and opportunity
analysis
Evaluation of solution performance typically occurs after a solution has been released. Therefore, it is more likely that the
evaluation of solution performance will occur during portfolio or program activities rather than project activities.
Data to evaluate the business value are often measured by and obtained from the business area that takes ownership of the
solution or by instrumentation that has been built into the product
INPUTS
Business Case; it is an authoritative source where expected benefits have been stated
Business Goals and Objectives; They provide the context for evaluating solution performance, because
they are a measurable description of the expected business value.
Evaluated Acceptance Results: are comparisons between the acceptance criteria and the actual results,
and the root cause for variances between them.
A product that exceeds expectations can provide a basis for future opportunities. A product that does
not meet expectations may have defects, which will necessitate analysis of the cost to address the
defects and the business impact of addressing them or accepting them.
Performance Data: a quantified output of a product.
They are used to determine the actual business value of a product by assessing the performance data
before and after a release. Any performance data from a prior version of a product or manual process
represent a baseline
Solution Evaluation Approach: provides the agreements made about how solution evaluation activities
will be performed.
It identifies which types of metrics will be used to evaluate whether the expected business value has
been achieved. It explains how solution performance will be evaluated. Because solutions can be
evaluated long after their release, the original solution evaluation approach may need to be updated
over time based on the current state
Cost-Benefit Analysis; used to determine the benefits provided by a

project or solution against its costs.
Focus Groups
Interviews
Observation
Product Portfolio Matrix: also known as a growth-share matrix, is a
market analysis quadrant diagram used by some organizations to
qualitatively analyze their products or product lines. One axis reflects
market growth (or demand for a product) from low to high, while the
other reflects the market share of the organization from low to high.
The matrix provides a quick visual way to evaluate which products are
meeting or exceeding performance expectations in the marketplace,
and as a result, can contribute to evaluating the performance of a
product.
Prioritization Schemes; can be used to rank the value of the benefits obtained from the solution as well
as the severity of any challenges it creates. Doing so can provide a way to consider whether the benefits
outweigh the challenges and vice versa
Root Cause and Opportunity Analysis; can help uncover the reasons why the actual business value
either did not meet or possibly exceeded expectations and where there may be further product
improvement opportunities. The results of root cause and opportunity analysis can be used when
making decisions about new products and whether to enhance, retire, or discontinue existing products
OUTPUTS
Assessment of Business Value: the result from comparing expected business value from a solution
against the actual value that has been realized. If the desired business value was not achieved, the
assessment includes the reasons why.
The assessment is used to make decisions about whether to develop a new product or to enhance,
retire, or discontinue an existing product. The work done to implement any recommendations will need
to be prioritized as part of the ongoing planning activities the organization performs for portfolio or
program management.
Aspects to be
Adaptive Predictive
Tailored
Name Evaluate Solution Performance
After a solution is launched, performance data are used to compare business value to what was
expected. Subjective and objective evidence is collected. Root causes are identified for deviations from
Approach what was expected. Recommendations may be made to address reducing the deviations. Root causes
become input into decisions to enhance, maintain, replace, or discontinue the product.
Deliverables Assessment results can be formally documented or not.

9.2 DETERMINE SOLUTION EVALUATION APPROACH
1. Metrics and KPIs 1. Elicitation techniques 1. Solution evaluation approach

2. Product scope 2. Group decision-making
3. Situation statement techniques
3. Prioritization schemes
4. Retrospectives and lessons
learned
The solution evaluation approach should be defined as early as possible in the product development life cycle because some
of the metrics identified in it may require capturing additional information, above and beyond what the product itself
requires.
Without early definition, there is a risk that necessary information will be expensive or impossible to obtain. When considering
new metrics, the cost of capturing actual measurements and reporting on them is an important factor.
INPUTS
Metrics and KPIs: a metric is a set of quantifiable measures used to evaluate a solution or business. In
solution evaluation, a metric defines how solution performance can be quantified.
Key performance indicators (KPIs) are a related type of metric, usually defined by an organization’s
executives, used to evaluate an organization’s progress toward meeting its objectives or goals.
Product Scope; provide suggestions as to what types of information should be collected and measured
for evaluation purposes.
Situation Statement; the wording of the situation statement may suggest ways to measure whether or
not the problem or opportunity has been addressed. The situation statement might also be used to
determine how, when, and how frequently a solution should be evaluated.
Document Analysis
Interviews
Group Decision-making Techniques; used to reach consensus about the solution evaluation approach.
Prioritization Schemes; the interest in obtaining information needs to be balanced against the cost of
obtaining and communicating that information. The balance is achieved through decision making and
may require prioritizing among the proposed metrics.
OUTPUTS
Solution Evaluation Approach: describes when and how a solution will be evaluated, the types of
metrics that will support evaluation, the feasibility of collecting and communicating the actual
performance data for these metrics, and who is responsible for conducting the evaluation and
communicating results
Aspects to be
Adaptive Predictive
Tailored
Name Not a formally named process Determine Solution Evaluation Approach
Considered part of initial planning and taken into
account when defining acceptance criteria,
The approach for Solution Evaluation is defined
creating a definition of done, and during
Approach coordination with quality assurance. The
as part of planning and prior to defining
acceptance criteria.
decisions may be documented informally or
discussed among the team.
The solution evaluation approach becomes a
component of the business analysis plan.
9.3 EVALUATE ACCEPTANCE RESULTS AND ADDRESS
DEFECTS
1. Acceptance criteria 1. Prioritization schemes 1. Evaluated acceptance results

2. Actual acceptance results 2. Root cause analysis
4. Variance analysis
The pass/fail aspect of comparing actual results from acceptance testing to testing criteria is typically a task within the testing
discipline. Business analysis is then needed to consider the magnitude and severity of the defects, to determine their root
cause, to identify risks associated with them, and to identify and recommend ways to address them.
INPUTS
Acceptance Criteria; a key input because they indicate the conditions against which the solution is
being tested
Actual Acceptance Results: contain the pass/fail results from comparing test results against the
acceptance criteria, often provided by a quality control team. In business analysis, the actual acceptance
results are then analyzed to determine the reasons for any differences between the test results and
acceptance criteria and to recommend how to address the defects.
Prioritization Schemes; can be used to rank each defect based on its severity and how likely a user is to
encounter it, as well as on the impact of not fixing the defect.
Root Cause Analysis; can be used to discover the reasons why actual results did not meet the
acceptance criteria. These root cause reasons will also figure into decisions about whether or not to
move forward to obtain solution acceptance for a release.
Traceability Matrix; can be used to establish relationships among product information, deliverables,
and project work to ensure that each relates back to business objectives
As part of evaluating acceptance results, a traceability matrix can be used as a tool to assess the
business impact of not addressing variations from acceptance criteria and defects; for example, there
could be a significant business impact from not addressing defects associated with features that trace to
a high-priority objective.
Variance Analysis; Irrespective of product life cycle, when there are significant differences between the
acceptance criteria and actual results from testing, variance analysis may be applied to consider causes
of the differences
OUTPUTS
Evaluated Acceptance Results: a summarized comparison between the acceptance criteria and the
actual acceptance results, along with the root cause for variances or defects, the analysis of the cost to
address the defect, and the business impact of addressing it or accepting it.
Some organizations will track the evaluated acceptance results and recommendations in logs. When
evaluated acceptance results are communicated, recommendations about ways to address the defect
may be included.
For organizations that make it a practice to maintain documentation about their products and projects,
another type of evaluated acceptance result can be obtained by comparing approved requirements to
as-built documentation.
Aspects to be
Adaptive Predictive
Tailored
Not a formally named process; performed
Evaluate Acceptance Results and Address
Name as part of the work to demonstrate and
Defects
obtain feedback on the solution
Typically covers a slice of product capabilities at a
time, along with the acceptance criteria Performed on a segment of the product that is to
associated with those capabilities. Demonstrate be delivered as part of a release or the entire
what was developed during the most recent product. Use evaluated acceptance results and
iteration, obtain feedback from decision makers, the acceptance criteria as a starting point to
Approach and add defects that need to be addressed to determine root cause for variances or defects.
the backlog for prioritization. When conducted for Consider the costs to address the defects and the
a specific user story, if the demonstration does business impacts of addressing or accepting
not prove conformance to the acceptance criteria, them. Provide recommendations for how to
the entire story can be rejected and returned to address the defects.
the backlog to be reprioritized.
Documentation of evaluated acceptance results,
Deliverables Additions of defects to the backlog.
along with any associated change requests.
9.4 OBTAIN SOLUTION ACCEPTANCE FOR RELEASE
1. Approved requirements 1. Facilitated workshops 1. Release decision

2. Evaluated acceptance results 2. Group decision-making
3. Product risk analysis techniques
4. Readiness assessment
5. Stakeholder engagement and
6. Transition plan
The key benefit of this process is the creation of an agreed-upon break between building a solution and releasing a solution
for acceptance by the stakeholders
For solution acceptance, the term release may refer to releasing a solution or a segment of a solution into a production
environment while its development team is still responsible for it. It can also refer to releasing a solution or a segment of it to
the operational area that will take responsibility for it.
INPUTS
Approved Requirements; provide the baseline for comparisons made in release decisions between
what was approved for the solution and what was actually implemented in the product.
Evaluated Acceptance Results; provide concrete evidence of whether or not the solution has met or
exceeded expectations. Any recommendations within evaluated acceptance results for how to deal with
the discrepancies may impact when and whether a solution is accepted for release.
Product Risk Analysis; this context is required when seeking solution acceptance for a release to
determine the degree to which the product risks have been addressed. Product risks not addressed
within the duration of the project may be transferred to operational teams to manage going forward.
Readiness Assessment; provides an evaluation of the ability of an organization to transition to the
future state enabled by the solution. It also identifies risks to achieving readiness for the transition, and
may also propose responses for how to address those risks.
Stakeholder Engagement and Communication Approach; includes information about which roles are
accountable for the release decision and how the release decision will be made.
Transition Plan; provides the information needed to coordinate and ensure that the release of the
solution will occur at a time when the business can accept the changes and that any interruptions
caused by the transition itself are not in conflict with other in-process programs and project work.
Facilitated Workshops; release decisions should be made during a facilitated workshop to allow all
stakeholders to hear the rationale for the decisions made. The individuals who evaluated the acceptance
criteria should attend and contribute to decision making. It can be helpful to provide summarized
information in tabular or visual form (i.e., charts/graphs/pictorial) whenever possible, to help decision
makers render their decisions
Group Decision-making Techniques; To make the release decision, group decision making is
conducted using an agreed-upon model for reaching a decision. The decision model should be
identified as part of the stakeholder engagement and communication approach.
OUTPUTS
Release Decision: may permit the release or partial release of the solution, delay it, or disapprove and
prevent it.
A release decision often includes a sign-off. The formality of the sign-off depends upon the type of
project, the type of product, the project life cycle, the scale of the release, and corporate and regulatory
constraints.
Organizations with informal sign-off practices need to obtain sign-off in the manner that is acceptable
to the organization.
Aspects to be
Adaptive Predictive
Tailored
part of Demonstration and Feedback. For
Obtain Solution Acceptance for
Name large-scale implementations, there may be a
Release
formal process to obtain solution acceptance
for release
Often, verbal approval alone is obtained with the product owner, as
part of demonstration and feedback, that a solution or solution
segment meets the definition of done and can be released to
production. For a full solution release using an adaptive life cycle, the
A formal meeting to review inputs and render a
approach may match what
decision on an entire solution or a substantial
is done in a predictive life cycle. Some large organizations are
segment of a solution, as part of a phased
moving to a DevOps approach, to coordinate activities and improve
Approach collaboration between development and operational areas. DevOps
release. This formal meeting to make the release
decision may be part of an overall release
may also use automated practices to support release management,
management approach, which coordinates the
such as continuous
release of all products.
integration and automated regression testing.
These approaches can streamline the way organizations push
releases to production and can make a release almost seamless with
its approval.
Deliverables Release decision with whatever level of formality of documentation is required.

THANK YOU
@Ayman_AlDhahri www.aymandh.sa

العرض التقديميpmi Pba

Uploaded by

Copyright:

Available Formats

العرض التقديميpmi Pba

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

العرض التقديميpmi Pba

Uploaded by

Copyright:

Available Formats

PMI BUSINESS ANALYSIS

EXAM PREPARATION COURSE

Educational Business Analysis Training in Business

Candidates for PMI-PBA® certification must follow a standard

The role delineation study for business analyst was instrumental in

Candidates are urged to use the Examination Content Outline to

Scored Questions Unscored Questions Total

Allotted Time: 4 Hours

PMI Member Non-PMI

Project requirements and quality requirements. These requirement types are

It would be difficult to accurately describe the work needed to deliver the

“All elements needed to produce a solution successfully. Product

Product Information include:

“Something that is produced to deliver measurable business value to meet

Needs Assessment. Analyzing current business problems or opportunities to

Factors that impact Business Analysis tailoring:

Inputs Tools & Techniques Outputs

1. Assessment of business value 1. Benchmarking 1. Business need

Enterprise Environmental Factors (EEFs)

Inputs Tools & Techniques Outputs

1. Enterprise and business 1. Business architecture 1. Current state assessment

Capability Framework Sample

Pareto Diagram Sample

SWOT Analysis: a technique for analyzing the strengths

Inputs Tools & Techniques Outputs

1. Business need 1. Affinity diagram 1. Business goals and objectives

Feature Model Sample

Kano Model Sample

Purpose Alignment Sample

1. Business goals and objectives 1. Benchmarking 1. Feasibility study results

1. Business goals and objectives 1. Facilitated workshops 1. Product roadmap

Deliverables Product Roadmap

1. Business goals and objectives 1. Document analysis 1. Business case

1. Business case 1. Document analysis 1. Charter

Document Analysis; reviewing organizational charts to identify a potential list of stakeholders or

1. Elicitation results 1. Brainstorming 1. Stakeholder register

Elicitation Results (Unconfirmed/Confirmed); At any point in time, unconfirmed and confirmed

1. Elicitation results 1. Job analysis 1. Updated stakeholder register

Elicitation Results (Unconfirmed/Confirmed)

RACI Chart Person

Activity Ann Ben Carlos Dina Ed

RACI Model Sample

TOOLS AND TECHNIQUES Direct Impact

1. Situation statement 1. Elicitation techniques 1. Stakeholder engagement and

A stakeholder engagement and communication approach often has five components:

1. Business analysis performance 1. Burndown charts 1. Business analysis plan

1. Business case 1. Elicitation techniques 1. Readiness assessment

1. Stakeholder engagement and 1. Elicitation techniques 1. Improved stakeholder

1. Business analysis plan 1. Burndown charts 1. Business analysis performance

1. Product scope 1. Brainstorming 1. Elicitation approach

1. Elicitation approach 1. Document analysis 1. Elicitation preparation materials

Preparing for elicitation include the following activities:

1. Elicitation preparation materials 1. Brainstorming 1. Unconfirmed elicitation results

Document Analysis; it can provide the following benefits:

Wireframe Sample Storyboarding Sample

1. Elicitation preparation materials 1. Document analysis 1. Confirmed elicitation results

Elicitation results may need to be:

1. Elicitation approach 1. Brainstorming 1. Analysis approach

Feature Model: a scope model that visually represents

Traceability Matrix Sample