PMI-PBA: Planning

Topic snapshot

Sample questions

These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Planning

A business analyst notices conflicting updates in three artifacts that describe the same requirement. The team works in parallel across business analysis, process design, and testing, and approved changes must stay synchronized for auditability. Based on the exhibit, which document control method is best to keep these parallel versions synchronized going forward?

Exhibit:

Requirement ID: REQ-27

Requirements package   v2.4  Baselined
Text: Validate address before order submission

Process model          v1.9  Working
Step shown: Validate address after payment

Test case TC-88        v1.3  Draft
Expected result: Address is checked after payment

• A. Separate baselines for each artifact stream
• B. Weekly reconciliation meetings and emailed updates
• C. One repository with linked versions and check-in/check-out
• D. Detailed file naming and local change logs

Best answer: C

What this tests: Planning

Explanation: The best method is a controlled repository that manages related artifacts together through version rules and check-in/check-out. That approach supports one authoritative version path, makes divergence visible quickly, and helps keep parallel requirement documents synchronized after approved changes.

This item tests document control for parallel versions. The exhibit shows one requirement represented in multiple artifacts, but the process model and test case no longer match the baselined requirement text. The best planning decision is to use a shared, controlled repository with version control, check-in/check-out, and trace links among the related artifacts.

That method helps because it:

• maintains one governed source for approved updates
• ties dependent artifacts to the same requirement ID and baseline
• prevents simultaneous uncontrolled edits
• exposes out-of-sync documents through version history and traceability

Meetings, email, naming rules, and local logs may help communication, but they do not actively control synchronization. The key takeaway is that parallel versions are best managed through centralized version control tied to traceability, not through manual coordination alone.

A controlled repository with linked artifacts and check-in/check-out creates one governed version path, so parallel documents stay aligned to approved changes.

Question 2

Topic: Planning

A BA is defining the requirements documentation standard for a hybrid product launch involving internal teams and an external vendor. Requirements will change frequently during sprints, and the sponsor expects clear traceability from business objectives to approved requirements, test cases, and change decisions. Which approach should the BA AVOID when establishing the document control standard?

• A. Assign unique requirement IDs linked to tests and change records
• B. Let each team keep local copies and rename files manually
• C. Set baselines and approval rules before replacing approved versions
• D. Use a shared repository with version history and access permissions

Best answer: B

What this tests: Planning

Explanation: Documentation control for requirements should support one authoritative source, visible version history, and stable trace links across lifecycle artifacts. In this scenario, decentralized local files with manual naming are the anti-pattern because they make it harder to know what is current, approved, and impacted by change.

The core concept is selecting document control methods that make requirements traceable and versioned in a disciplined way. Because this effort has multiple teams, frequent change, and a need to connect objectives, requirements, tests, and change decisions, the standard should preserve a clear current state and a reliable history.

• Use a shared repository so stakeholders work from the same approved content.
• Use stable requirement identifiers so links remain intact across analysis, testing, and change control.
• Baseline approved requirements and update them only through defined approval rules.

Keeping separate team copies and relying on filenames may seem convenient, but it creates conflicting versions, weakens auditability, and breaks confidence in trace relationships.

Manual local copies and file renaming weaken the single source of truth, audit history, and end-to-end traceability.

Question 3

Topic: Planning

A BA is defining the traceability approach for an upcoming release. Analyst time is limited, so the team wants only the level of traceability needed to monitor and validate requirements.

Exhibit:

Which traceability approach is best supported by the exhibit?

• A. Use lightweight source-to-story links for all items because analyst capacity is limited.
• B. Apply full bidirectional traceability to every requirement in the release.
• C. Use full bidirectional traceability for the regulatory and interface items, with lighter tracking for the UI and content items.
• D. Trace only from requirements to test cases because validation matters more than source and impact links.

Best answer: C

What this tests: Planning

Explanation: Traceability depth should be risk-based, not uniform. The exhibit contains two high-risk requirement sets with audit or integration consequences and two low-risk isolated changes, so full bidirectional traceability is justified only for the higher-risk items.

The core concept is tailoring traceability to the level needed for monitoring, validation, and change impact analysis. Full bidirectional traceability is most valuable when a requirement has regulatory or audit obligations, spans multiple systems, or could disrupt operations if changed incorrectly. In the exhibit, the transaction hold rules and settlement file update meet that threshold because they require stronger control from source through implementation and testing, and back again for impact analysis.

• Use fuller bidirectional links for compliance-sensitive, cross-system, or operationally critical requirements.
• Use lighter coverage for isolated, low-risk changes such as simple UI fields or content updates.
• Match traceability effort to consequence and complexity, not to every item equally.

A strategy that is uniformly heavy wastes effort, while one that is uniformly light leaves important requirements insufficiently controlled.

The exhibit shows full bidirectional traceability is warranted for high-risk, multi-system, and auditable requirements, while isolated low-risk changes need less coverage.

Question 4

Topic: Planning

A company is updating its claims platform with a remote internal team and an external vendor. Internal analysts use SharePoint, the vendor uses Jira and Confluence, and operations stores approval evidence in a controlled network folder. The sponsor will not fund an immediate tool migration, but approved requirements must remain versioned and traceable to vendor backlog items, test cases, and sign-off records. Which document control method is the best fit?

• A. Let each team manage versions locally and reconcile differences at milestones.
• B. Keep one approved baseline repository, with shared IDs, status codes, and linked copies.
• C. Use emailed documents with dated filenames for reviews and approvals.
• D. Make the vendor backlog tool the master record for all requirements.

Best answer: B

What this tests: Planning

Explanation: The best choice is a federated document control method: one authoritative repository for approved baselines, plus shared identifiers and status/version rules across other tools. That fits mixed repositories and remote teams while still supporting traceability, approvals, and vendor coordination.

When teams cannot move to a single tool, the BA should tailor document control around a single authoritative source for approved requirements and a common control standard across repositories. In this scenario, the key need is not convenience; it is preserving versioning, approval evidence, and end-to-end traceability across internal and vendor tools.

A sound approach is to:

• define one repository as the baseline source for approved requirements
• use common IDs, version labels, and status values in every repository
• link vendor backlog items, tests, and approval records back to those baseline items
• control updates through the agreed change and versioning process

This avoids the main failure in mixed-tool environments: multiple “masters” that drift out of sync. A full migration could work later, but it is not the best immediate fit under the stated constraints.

A federated control approach with one authoritative baseline and common versioning rules preserves traceability and approval control without forcing all teams into one tool.

Question 5

Topic: Planning

A BA is supporting a payroll system upgrade in a regulated company. The requirements package has been baselined. After design begins, HR requests a new requirement to let managers override tax withholding defaults. Trace links show dependencies to business rules, audit logging, interface mappings, test cases, and training materials. Before this change is approved, which impact criteria should the BA evaluate?

• A. Effects on linked rules, interfaces, tests, training, compliance, and the approved baseline
• B. Effects on user satisfaction, team workload, and sponsor priority
• C. Effects on current build tasks only, with trace links updated after implementation
• D. Effects on requirement wording, approval date, and document version

Best answer: A

What this tests: Planning

Explanation: Before approving a baselined requirement change, the BA should perform impact analysis across all trace-linked artifacts and constraints. In this scenario, the requested override affects regulated business rules and downstream items such as interfaces, tests, training, and compliance, so those impacts must be understood before approval.

The core concept is controlled requirements change using traceability. Once requirements are baselined, approval should be based on impact analysis of the full change footprint, not just perceived benefit or effort. Here, the override request could alter business rules, audit needs, interface behavior, test coverage, training content, and compliance obligations, and it may also affect the approved scope and delivery commitments.

• Identify all upstream and downstream trace links.
• Assess impacts on dependent artifacts, risks, and compliance.
• Determine whether the baseline, schedule, cost, or acceptance expectations must change.

Administrative updates such as versioning are important, but only after the impact has been evaluated and the change decision is made.

A controlled change decision requires analyzing upstream and downstream trace links plus the effect on the baselined requirement set.

Question 6

Topic: Planning

A health insurer is planning a provider portal feature for address changes. Stakeholders agree on this acceptance criterion for post-launch evaluation: “Within 90 days of release, at least 65% of address-change requests must be completed in the portal in under 4 minutes without contact center assistance.” Build freeze is next week, and only one new reporting requirement can be added. Which evidence should the business analyst prioritize defining now?

• A. Post-launch survey results on provider satisfaction with the new portal flow
• B. UAT results proving representative users can complete the workflow in under 4 minutes
• C. Audit trail records showing who approved each address change and when
• D. Production transaction logs capturing request start time, completion time, and whether agent assistance occurred

Best answer: D

What this tests: Planning

Explanation: The best evidence is the data that directly measures the acceptance criterion in production. Here, the team needs operational records that show how many requests were completed, how long they took, and whether users needed assistance.

When defining business metrics and acceptance criteria, the business analyst should identify the exact evidence needed for later evaluation. This criterion has three measurable parts: the proportion of requests completed, the elapsed time per request, and whether contact center assistance was required. Production transaction data with timestamps and an assisted/unassisted indicator allows the evaluator to measure all three using actual post-release behavior over the 90-day period.

UAT evidence, satisfaction feedback, and approval audit logs may all be useful, but they are secondary because they do not directly verify the stated acceptance criterion in live operations. The strongest planning choice is the evidence that enables objective calculation of the agreed metric later.

This is the only option that provides objective live-use data for the percentage, duration, and assistance elements of the acceptance criterion.

Question 7

Topic: Planning

A BA is reviewing the requirements management plan for an 8-week enhancement to an internal expense system. One existing scrum team will deliver workflow updates and two new reports for a single business unit. There are no new vendors or interfaces, and one compliance reviewer must confirm regulatory wording.

Exhibit: Requirements management plan excerpt

Documentation: BRD, use cases, data dictionary, interface spec,
decision log, and user stories for every feature
Approval: each requirement signed by product owner, sponsor,
compliance, operations, and QA
Baseline/change: backlog baselined after each sprint planning;
any change requires a formal request and monthly CCB review
Traceability: each story linked to business objective, test case,
training material, and deployment checklist
Status: weekly 12-page requirements report

Which interpretation is best supported by the exhibit?

• A. Tailor the plan down; keep traceability but simplify approvals and change control.
• B. Remove documented controls and rely on sprint demos alone.
• C. Keep the plan as written because compliance is involved.
• D. Tighten the plan further with a frozen upfront baseline.

Best answer: A

What this tests: Planning

Explanation: The exhibit shows a short, low-risk agile enhancement, yet the plan requires multiple heavyweight artifacts, five-way sign-off, formal change requests, and a monthly CCB for routine backlog updates. That is more control than the project needs; the plan should be tailored down while preserving essential compliance traceability.

A requirements management plan should be scaled to delivery approach, complexity, risk, and stakeholder needs. In this case, the work is limited in scope, handled by one existing scrum team, and has only targeted compliance involvement. That does not justify a stack of formal specifications, five separate approvals for each requirement, and monthly change board review for ordinary backlog updates. Those controls will slow refinement and adaptation without adding proportional value.

• Keep the controls that protect outcomes: ownership, traceability to objectives and tests, and compliance review where needed.
• Reduce controls that overburden the team: excess documentation, too many approvers, and formal change requests for normal iterative reprioritization.
• Use lighter versioning and approval methods consistent with agile delivery.

The closest distractor assumes any compliance need requires maximum governance, but the better practice is targeted control, not unnecessary overhead.

The short, low-risk agile effort needs essential compliance traceability, not multi-signature approvals and monthly CCB control for routine backlog changes.

Question 8

Topic: Planning

A BA joins a project to launch a customer self-service portal. The business case states the goal is to reduce call-center volume by 20% and improve customer satisfaction within 9 months. In the kickoff meeting, stakeholders begin debating screen layouts and field validations, but the BA has not yet reviewed the business case and goals with the group. What should the BA do next?

• A. Document screen layouts and validation rules from the kickoff discussion.
• B. Create a traceability matrix for the proposed portal features.
• C. Review the business case, objectives, and success measures with stakeholders.
• D. Request sign-off on a detailed requirements baseline.

Best answer: C

What this tests: Planning

Explanation: The best next step is to align stakeholders on the business case, goals, and success measures before discussing detailed solution content. Those items provide the context for business analysis work, while screen layouts and validation rules are details better handled later in delivery.

In Planning, the BA should first use the business case and project objectives to frame the analysis effort. Here, the team has jumped into detailed solution discussion before confirming the business problem, desired outcomes, and how success will be measured. Reviewing that context with stakeholders helps the BA set scope boundaries, identify what information matters now, and plan elicitation around value rather than around premature design detail.

• Confirm the business need and expected outcomes.
• Align stakeholders on goals, scope, and success measures.
• Then elicit and analyze detailed requirements.

Starting with layouts or validation rules risks solving the wrong problem, and traceability or baselining is more appropriate after requirements are defined.

This establishes the business analysis context before the team moves into detailed solution discussions.

Question 9

Topic: Planning

A BA is defining document control standards for a regulated product update. One requirements baseline has already been approved, and auditors often ask why later changes were made. The BA reviews the current repository practice.

Exhibit:

Requirements package control excerpt
- BRD v1.0: approved baseline
- BRD v1.1: compliance updates saved over v1.0
- RTM: current links only; superseded rows deleted
- Change rationale: captured in meeting minutes only

Which action best addresses the weakness shown in the exhibit?

• A. Preserve approved baselines as read-only versions and link each change to a decision record.
• B. Re-baseline the full package after every working-session update.
• C. Store rationale only in sign-off emails once development begins.
• D. Rename each file with the latest date and keep one active RTM.

Best answer: A

What this tests: Planning

Explanation: The exhibit shows that the approved baseline was overwritten and the reasoning for changes is scattered in meeting notes. Effective document control should preserve each approved baseline, keep prior versions accessible, and connect every approved change to its decision history.

The core issue is loss of baseline integrity and loss of decision history. An approved baseline should be frozen so the team can always show what was approved at that point in time. Later changes should create a new controlled version rather than overwrite the baseline, and each change should be traceable to a decision or approval record that explains the origin and rationale.

A sound document control approach here would:

• keep approved versions read-only
• assign unique version identifiers
• retain superseded traceability entries instead of deleting them
• link requirement changes to change decisions or approvals

Date-based file naming alone does not preserve approval points, and re-baselining every draft edit would create unnecessary control overhead. The key is controlled versioning plus preserved historical rationale.

This creates an auditable history by protecting the baseline and tying later changes to their approval and rationale.

Question 10

Topic: Planning

A regional bank approved a project to add online appointment scheduling for branch services. The business case says the project will improve customer experience and branch efficiency, and the sponsor wants detailed elicitation to start immediately. However, branch managers want shorter lobby wait times, the call center wants fewer scheduling calls, and sales leaders want more advisory appointments. Budget and target launch quarter are already approved. Before major business analysis work proceeds, which business case element should the BA clarify first?

• A. Initial scope boundaries for the first release
• B. Funding allocation across business units
• C. Approval workflow for requirement documents
• D. Quantified benefits and success measures

Best answer: D

What this tests: Planning

Explanation: The business case is too vague about what success looks like. When stakeholders want different outcomes, the BA should first clarify the expected benefits and how they will be measured so later analysis, prioritization, and tradeoff decisions stay aligned to value.

The key concept is using the business case to establish context for business analysis work. In this scenario, stakeholders disagree on whether the initiative should optimize wait times, reduce call volume, or increase advisory appointments. Those are different value outcomes, so starting detailed elicitation now would likely produce a large set of competing requirements without a clear basis for prioritization.

Clarifying quantified benefits and success measures first gives the BA a decision frame for later work:

• identify the primary business objective
• define how success will be measured
• align stakeholders on expected value
• use that context to prioritize requirements

Scope, funding detail, and document approvals matter, but they do not resolve the core ambiguity about why the initiative is being pursued and what outcomes matter most.

Conflicting stakeholder priorities make the expected business value unclear, so measurable benefits and success criteria must be defined before detailed requirements can be meaningfully prioritized.

Continue with full practice

Use the PMI-PBA Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Related focused pages

• Free PMI-PBA Full-Length Practice Exam
• PMI-PBA: Needs Assessment
• PMI-PBA: Analysis
• PMI-PBA: Traceability and Monitoring
• PMI-PBA: Evaluation

Free review resource

Read the PMI-PBA guide on PMExams.com, then return to PM Mastery for timed practice.