10.1 Business Analysis in Predictive and Agile Approaches

CAPM Certified Associate in Project Management Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CAPM Exam Overview

1.1 About the CAPM Exam 1.2 PMBOK 7th Edition Overview 1.3 Exam Content Outline (ECO) 1.4 CAPM vs. PMP: Understanding the Differences

2 Chapter 2: Project Life Cycles and Processes (Domain 1, Tasks 1-2)

2.1 Projects, Programs, and Portfolios 2.2 Project Life Cycle Phases 2.3 The Five Process Groups 2.4 The Ten Knowledge Areas

3 Chapter 3: Project Management Planning (Domain 1, Task 2)

3.1 The Project Management Plan 3.2 Scope Management and the WBS 3.3 Schedule Management 3.4 Cost Management and Earned Value 3.5 Quality Management

4 Chapter 4: Project Roles, Responsibilities, and Ethics (Domain 1, Tasks 3-4)

4.1 Project Roles and Responsibilities 4.2 Leadership and Emotional Intelligence 4.3 Risk Management Fundamentals 4.4 PMI Code of Ethics and Professional Conduct 4.5 Problem-Solving Tools and Techniques

5 Chapter 5: Resource, Communication, and Stakeholder Management (Domain 1, Tasks 2-3)

5.1 Resource Management 5.2 Communications Management 5.3 Stakeholder Management 5.4 Procurement Management 5.5 Issues, Risks, Assumptions, and Constraints

6 Chapter 6: Predictive, Plan-Based Methodologies (Domain 2)

6.1 When to Use a Predictive Approach 6.2 WBS, Work Packages, and Activity Definition 6.3 Predictive Project Controls and Artifacts 6.4 Critical Path and Schedule Calculations

7 Chapter 7: Agile Frameworks and Methodologies (Domain 3, Tasks 1-3)

7.1 When to Use an Adaptive (Agile) Approach 7.2 The Scrum Framework 7.3 Kanban, XP, and SAFe 7.4 Agile Planning, Estimation, and Metrics 7.5 Agile Project Controls and Artifacts

8 Chapter 8: Business Analysis Roles and Stakeholder Communication (Domain 4, Tasks 1-2)

8.1 Business Analysis Roles and Responsibilities 8.2 Stakeholder Communication in Business Analysis 8.3 Business Case and Needs Assessment

9 Chapter 9: Requirements Gathering and Product Roadmaps (Domain 4, Tasks 3-4)

9.1 Requirements Gathering Approaches 9.2 Requirements Traceability Matrix 9.3 Product Roadmaps

10 Chapter 10: BA Methodologies and Requirements Validation (Domain 4, Tasks 5-6)

10.1 Business Analysis in Predictive and Agile Approaches 10.2 Acceptance Criteria and Requirements Validation 10.3 Business Analysis Tools and Techniques Summary

10.1 Business Analysis in Predictive and Agile Approaches

Key Takeaways Explain This Topic AI

Business Analysis is Domain 4 of the CAPM exam and carries the second-largest weight at 27% of the 150-question test, so methodology questions in this domain appear roughly 40 times across scored and pretest items.

In predictive projects, business analysis is front-loaded: requirements are elicited, documented, baselined, and formally signed off before design and build begin.

In agile projects, business analysis is continuous and just-in-time: the Product Owner refines a prioritized product backlog through backlog refinement and sprint planning.

The same BA tasks (elicit, analyze, document, validate) occur in both approaches, but the artifacts, timing, and change handling differ sharply.

Hybrid projects pair a predictive business-requirements layer with agile solution-requirements delivery, a pattern the exam tests with scenario questions.

Last updated: June 2026

Where Domain 4 Sits on the Exam

The Certified Associate in Project Management (CAPM) exam is 150 questions (135 scored plus 15 unscored pretest items) answered in a 3-hour window with one 10-minute break after question 75. The four domains are weighted: Project Management Fundamentals 36% , Predictive Methodologies 17% , Agile Frameworks 20% , and Business Analysis 27% . Domain 4 is therefore the second-heaviest section and supplies roughly 40 questions.

The single most-tested idea in Task 5 is that the BA process does not change, but the package does . You always elicit, analyze, document, and validate requirements. What shifts with the development approach is when you do it, how much you write down, and how you handle change.

Business Analysis in Predictive Projects

In a predictive (plan-driven, "waterfall") project, business analysis is front-loaded into the early phases and baselined before build begins.

BA activity by phase

Phase Primary BA activity
Initiating Needs assessment, business case input, stakeholder identification

Planning Elicitation, analysis, documentation, requirements baseline, Requirements Traceability Matrix (RTM) creation

Executing Requirements clarification, change-request impact analysis
Monitoring & Controlling Requirements status tracking, scope verification support
Closing Requirements completion check, lessons learned
Core predictive artifacts

Business Requirements Document (BRD) captures high-level business needs and objectives (the why ).

Functional Requirements Specification / Software Requirements Specification (SRS) details what the solution must do (the what ).

Non-functional requirements define performance, security, scalability, and usability targets.

Requirements Traceability Matrix (RTM) links each requirement to its source, design, deliverable, and test case.

Use cases, process flow diagrams, and a data dictionary add structured detail.

Predictive BA characteristics

Comprehensive documentation before development begins.

Formal sign-offs at phase gates create an approved requirements baseline.

Any change runs through integrated change control and a change control board.

A dedicated business analyst role is typically separate from the build team.

Sequential: requirements are treated as "complete" before design starts.

Business Analysis in Agile Projects

In an agile project, business analysis is continuous and just-in-time , organized around the cadence of iterations rather than phases.

BA activity by Scrum event

Scrum event Primary BA activity
Backlog refinement Write user stories, add acceptance criteria, estimate, re-prioritize
Sprint planning Clarify the stories pulled into the sprint, answer team questions
Daily Scrum Resolve requirement questions that surface during the day
Sprint Review Validate the increment against acceptance criteria with stakeholders
Retrospective Improve the requirements/refinement process itself
Core agile artifacts

Product backlog is the single, prioritized list of everything wanted (epics and user stories).

User stories follow the lightweight form: As a [role], I want [goal], so that [benefit] .

Acceptance criteria define when a story is "done" enough to accept.

Story maps, personas, and wireframes/prototypes support shared understanding.

In agile the dedicated BA role is often absorbed by the Product Owner , who owns the backlog and accepts the work, or a BA is embedded in the team.

Why the agile package is smaller

Agile does not skip analysis; it defers detailed elaboration until the last responsible moment. A user story may sit in the backlog for months as a one-line placeholder and only gain full acceptance criteria during the refinement session just before the sprint that will build it. This progressive elaboration reduces waste because requirements that get deprioritized or dropped never incur the cost of full documentation. The risk the exam tests is insufficient written detail for audit, regulatory, or contractual needs — the mirror image of the predictive risk that requirements go stale by the time a long sequential build finishes.

Neither approach is universally "better"; the right choice depends on how stable the requirements are and how much regulatory documentation the domain demands.

Side-by-Side Comparison (high-yield)

Aspect Predictive BA Agile BA
Timing Upfront, before build Continuous, every iteration
Documentation Comprehensive, formal Lightweight, "just enough"
Requirement format BRD, SRS, use cases User stories + acceptance criteria
Change handling Formal change control Welcome change, re-prioritize backlog
Traceability Formal RTM Backlog hierarchy (epic to story)
Sign-off Approval before next phase Acceptance at Sprint Review
BA role Dedicated, separate Product Owner or embedded BA

Common trap: a scenario states the team "welcomes a stakeholder's new request mid-iteration and adds it to the backlog" — that is agile , not a change-control failure. If the scenario instead says a requirement is "already baselined and signed off," the correct response is to raise a change request , not to quietly build it.

Hybrid Projects

Hybrid work combines both. The exam favors the pattern where business requirements stay predictive (formal BRD, compliance, architecture) while solution requirements go agile (stories refined iteratively, prototyped UI). A typical hybrid "requirements funnel" pushes an approved business case and BRD into an agile backlog for iterative delivery, with predictive documentation kept for audit and compliance.

Hybrid patterns you may be asked to recognize

Two-speed BA: high-level scope and milestones are planned predictively while features are delivered in agile sprints.

Compliance overlay: the team delivers iteratively but maintains formal traceability so regulators or auditors can confirm every requirement was tested.

Phase-gated agile: agile sprints run inside predictive phase gates, so a stage-gate review still approves funding before the next block of iterations.

For any Task 5 scenario, do not memorize a single "correct" methodology. Read for the cues: words like baseline , sign-off , phase gate , and change control board signal predictive ; backlog , user story , sprint , Product Owner , and welcome change signal agile ; a split between stable business requirements and evolving solution features signals hybrid . Picking the answer that matches the cues, rather than your personal preference, is how Domain 4 rewards you.