Knowledge + Practice

CCNA Product Questions

43 questions · Product · All types, answers revealed

Practice these questions Domain overview All questions

1

Multi-Selectmedium

Which THREE are common pitfalls in product backlog management?

Select 3 answers

A.Having a backlog that is too large to navigate.

B.Involving the team in the planning process.

C.Failing to refine the backlog regularly.

D.Having a clear and prioritized backlog.

E.Ignoring technical debt until it causes failure.

AnswersA, C, E

An oversized backlog becomes unnavigable: items lose visibility, prioritisation degrades, and lower-value entries linger indefinitely. This directly violates the agile principle of a lean, ordered backlog refined continuously, so it qualifies as a recognised backlog management pitfall.

Why this answer

Option A is correct because an excessively large backlog becomes unnavigable, obscuring priorities and making it hard for the Product Owner to keep the most valuable items at the top for the team. Option C is correct because without regular backlog refinement (grooming), items grow stale, estimates become unreliable, and the team loses shared understanding of upcoming work. Option E is correct because deferring technical debt until it causes failures is a classic backlog-management pitfall that eventually cripples velocity and product stability.

Option B does not belong because involving the team in planning is a recommended agile practice, not a pitfall. Option D does not belong because a clear, prioritized backlog is the desired state of good backlog management, not a pitfall.

Exam trap

PMI-ACP often tests whether candidates can distinguish genuine agile anti-patterns from healthy practices, so options describing good behaviors (clear prioritized backlog, team involvement) are planted as distractors that sound plausible if you are scanning for 'problems' rather than evaluating each option on its merits.

Practice this question →

2

MCQhard

A Product Owner is ordering a product backlog for a mobile banking app. Two items are candidates for the next sprint: a regulatory compliance feature with a fixed legal deadline in three weeks, and a customer-delight feature expected to raise engagement significantly but with no external deadline. Using cost of delay reasoning, how should the Product Owner sequence these items?

A.Sequence the customer-delight feature first because it has the highest overall business value and will please the largest number of users.

B.Sequence the customer-delight feature first and negotiate a deadline extension with the regulator, since agile teams should avoid fixed-date commitments.

C.Split the team so both features are built simultaneously, accepting that neither may be fully complete by the regulatory deadline.

D.Sequence the regulatory compliance feature first because its cost of delay is high and time-critical due to the fixed legal deadline, then the customer-delight feature.

AnswerD

Cost of delay combines value and time sensitivity. The regulatory feature has a hard external deadline, so its cost of delay rises steeply and dominates the comparison, even if the delight feature has greater raw value. Sequencing the compliance work first protects the organization from penalties and preserves the option to deliver delight value afterward, which is the economically rational ordering.

Why this answer

Cost of delay weighs both the value of a feature and how much that value erodes over time. A regulatory item with a fixed legal deadline has a steeply rising cost of delay, so it should precede a higher-value but non-time-critical delight feature. This sequencing minimizes total economic loss and preserves the opportunity to deliver the delight value after the compliance obligation is met.

Exam trap

The trap here is ranking backlog items by raw business value alone and overlooking that time sensitivity can make a lower-value item more urgent.

Practice this question →

3

MCQeasy

Which of the following describes the 'INVEST' model for user stories?

A.Independent, Negotiable, Valuable, Estimable, Small, Testable.

B.Important, Notable, Validated, Explicit, Scalable, Technical.

C.Internal, New, Visible, Executable, Simple, Thorough.

D.Integrated, Necessary, Verified, Efficient, Structured, Tactical.

AnswerA

INVEST defines six quality criteria for user stories: Independent, Negotiable, Valuable, Estimable, Small and Testable. This directly answers the stem's request for the model's description, matching the acronym's exact terms. No other option enumerates these attributes, so it satisfies the question precisely.

Why this answer

The INVEST model is a widely used acronym in agile for evaluating user story quality: Independent, Negotiable, Valuable, Estimable, Small, and Testable. These six criteria ensure stories are self-contained, flexible in implementation, deliver business value, can be sized, fit within an iteration, and have clear acceptance criteria.

Exam trap

PMI-ACP often tests whether candidates recognize the exact INVEST acronym versus plausible-sounding fabricated expansions — memorizing the six words verbatim is essential because distractors use similar-sounding but incorrect terms.

How to eliminate wrong answers

Option B is wrong because 'Important, Notable, Validated, Explicit, Scalable, Technical' is a fabricated acronym with no basis in agile literature. Option C is wrong because 'Internal, New, Visible, Executable, Simple, Thorough' is also invented and doesn't match any recognized agile framework. Option D is wrong because 'Integrated, Necessary, Verified, Efficient, Structured, Tactical' is a made-up expansion that misrepresents the INVEST criteria.

Practice this question →

4

Multi-Selectmedium

Which TWO of the following are characteristics of a good product vision?

Select 2 answers

A.It includes a complete list of all product features.

B.It is concise and easy to understand.

C.It is written in a detailed technical specification.

D.It is updated daily by the Scrum Master.

E.It inspires the team and stakeholders.

AnswersB, E

A concise, easily understood vision communicates direction without ambiguity, letting the team and stakeholders grasp the product's purpose quickly. This satisfies the question's requirement for a defining characteristic, since brevity supports shared understanding and guides decisions throughout iterative delivery.

Why this answer

Option B is correct because a good product vision must be concise and easy to understand so that everyone—developers, stakeholders, and customers—can quickly grasp the product's purpose and direction without wading through complexity. Option E is correct because an effective vision inspires the team and stakeholders, providing a shared, motivating long-term goal that guides decisions and sustains engagement throughout the product's lifecycle. In contrast, option A is wrong because a vision is not a complete feature list; detailed features belong in the product backlog, not the vision.

Option C is wrong because a vision should be high-level and business-oriented, not a detailed technical specification. Option D is wrong because the vision is owned by the Product Owner (with stakeholder input) and is meant to be stable over time, not updated daily by the Scrum Master.

Exam trap

PMI-ACP often tests the confusion between the product vision (high-level, inspiring, stable) and the product backlog or roadmap (detailed, tactical, frequently updated), so candidates must not attribute backlog characteristics to the vision.

Practice this question →

5

Multi-Selecthard

Which THREE items should be in the Definition of Done (DoD)?

Select 3 answers

A.Code reviewed by a peer.

B.The team has been rewarded with a bonus.

C.The CEO has signed off on the code.

D.Passing all automated tests.

E.Documentation updated for the feature.

AnswersA, D, E

Peer review is a quality gate applied to every increment, so it belongs in the Definition of Done as a consistently enforced criterion rather than a per-story choice. It satisfies the stem's demand for items applying uniformly across all work, distinguishing shared completion standards from acceptance criteria that vary by backlog item.

Why this answer

Option A is correct because peer code review is a standard quality gate in a Definition of Done, ensuring another developer inspects the change for defects, standards compliance, and maintainability before it is considered complete. Option D is correct because passing all automated tests verifies that the increment meets its acceptance criteria and has not broken existing functionality, which is a core DoD criterion. Option E is correct because updating documentation for the feature ensures knowledge transfer, maintainability, and supportability, all of which are typical DoD requirements.

Option B does not belong because rewarding the team with a bonus is a management or HR matter, not a quality criterion for a completed increment. Option C does not belong because CEO sign-off on code is not a practical or standard DoD item; the Product Owner, not the CEO, typically accepts the increment.

Exam trap

PMI-ACP often tests the difference between team-owned quality criteria (DoD) and management or executive actions, so the trap is selecting answers involving bonuses or executive sign-off that sound authoritative but are not part of the DoD.

Practice this question →

6

Multi-Selecthard

Which TWO of the following help ensure stakeholder alignment?

Select 2 answers

A.Ignoring stakeholder requests until the project is finished.

B.Keeping stakeholders isolated from the development team.

C.Frequent demonstrations of working software.

D.Sending lengthy weekly status reports that no one reads.

E.Maintaining an open and transparent product roadmap.

AnswersC, E

Frequent demonstrations of working software give stakeholders tangible, incremental visibility of delivered functionality, letting them validate progress and course-correct early. This recurring feedback loop keeps expectations and priorities aligned throughout the project, satisfying the stem's requirement for ensuring stakeholder alignment.

Why this answer

Option C (Frequent demonstrations of working software) is correct because regularly showing incrementally delivered, functioning software gives stakeholders concrete, verifiable visibility into progress and lets them validate that the product meets their needs, which builds shared understanding and alignment. Option E (Maintaining an open and transparent product roadmap) is correct because a visible, accessible roadmap communicates priorities, direction, and trade-offs so stakeholders share a common view of goals and can raise concerns early rather than after decisions are locked in. The remaining options do not support alignment: A (ignoring stakeholder requests) and B (isolating stakeholders from the development team) actively reduce communication and trust, while D (lengthy weekly status reports nobody reads) is a low-value, one-way communication channel that fails to create genuine shared understanding.

Exam trap

PMI-ACP often tests the misconception that more reporting equals more communication — candidates pick lengthy status reports because they sound 'professional,' when Agile alignment actually comes from working software demonstrations and visible roadmaps.

Practice this question →

7

MCQeasy

During a sprint, a team member discovers a small bug. Where should this task be added?

A.To the personal notepad of the Scrum Master.

B.To the product backlog.

C.To a separate bug-tracking document outside of the product tool.

D.To the project charter.

AnswerB

The product backlog is the single ordered list of all work not yet done, so a discovered bug is added there and prioritised by the Product Owner alongside other items. Sprint backlogs are fixed once the sprint starts, so only the product backlog can absorb it.

Why this answer

In Scrum, the product backlog is the single source of truth for all work that may be needed in the product, including new features, enhancements, and bug fixes. A bug discovered during a sprint should be added to the product backlog so the Product Owner can prioritize it against other items. This keeps all work transparent and prioritized in one place.

Exam trap

PMI-ACP often tests the misconception that bugs should be tracked separately or handled outside the product backlog — candidates must remember that all work, including bugs, belongs in the product backlog for the Product Owner to prioritize.

How to eliminate wrong answers

Option A is wrong because the Scrum Master's personal notepad is not a transparent artifact and does not feed into prioritization — work must live in the product backlog. Option C is wrong because tracking bugs outside the product tool breaks transparency and creates a parallel backlog that the Product Owner cannot prioritize. Option D is wrong because the project charter is a high-level document that authorizes the project; it is not a place to track sprint-level work items.

Practice this question →

8

MCQmedium

A product owner is refining the backlog. What is the best way to handle 'Technical Debt' items?

A.Keep them hidden from stakeholders to avoid concern.

B.Incorporate them into the backlog and prioritize them alongside features.

C.Ignore them until they cause a system crash.

D.Assign them to a separate 'technical' team only.

AnswerB

Technical debt represents genuine work requiring capacity, so listing it in the backlog alongside features lets the product owner prioritise it transparently against customer value. This satisfies the stem's refinement constraint by making debt visible and tradeable rather than hidden, preventing unplanned rework from silently eroding velocity in later sprints.

Why this answer

Technical debt items should be incorporated into the product backlog and prioritized alongside features, because they represent work needed to maintain or improve the product's quality and maintainability. The product owner, in collaboration with the team, can then decide when to address them based on value and risk. This ensures transparency and allows for informed trade-offs.

Exam trap

PMI-ACP often tests the misconception that technical debt should be hidden or handled separately — candidates must recognize that transparency and prioritization in the backlog are key.

How to eliminate wrong answers

Option A is wrong because hiding technical debt from stakeholders reduces transparency and can lead to poor decision-making and unexpected failures. Option C is wrong because ignoring technical debt until a crash occurs is reactive and can cause severe disruptions and higher costs. Option D is wrong because assigning technical debt to a separate team can create silos and does not integrate it into the product's overall priority; it also violates Agile's cross-functional team principle.

Practice this question →

9

MCQeasy

What is the primary function of the 'Product Vision'?

A.To list every feature to be built in the product.

B.To define the long-term purpose and goal of the product.

C.To track the budget spent on the development team.

D.To provide the specific daily meeting agenda.

AnswerB

The Product Vision articulates the long-term purpose and goal of the product, giving the team and stakeholders a shared destination that guides backlog prioritisation and release decisions. It is not a detailed requirements list or sprint plan; it provides enduring direction across the product's life.

Why this answer

The Product Vision is a concise, aspirational statement describing the long-term purpose, target customers, key benefits, and differentiators of the product. It aligns the team and stakeholders on the 'why' behind the product and guides prioritization decisions. It is not a feature list, budget tracker, or meeting agenda—those are artifacts of other processes.

Exam trap

The trap is confusing the Product Vision with the Product Backlog or a project charter—candidates often pick 'list every feature' (A) because they conflate vision with scope documentation.

How to eliminate wrong answers

Option A is wrong because listing every feature is the product backlog's role, not the vision's; the vision describes purpose, not scope. Option C is wrong because budget tracking is a financial/portfolio management activity, unrelated to the Product Vision. Option D is wrong because daily meeting agendas are tactical Scrum artifacts (e.g., Daily Scrum), not strategic vision elements.

Practice this question →

10

MCQeasy

A Scrum team is preparing for its first Sprint Review with a new stakeholder group. The Product Owner wants the review to focus on the actual product increment rather than a slide deck. Which approach best aligns with agile product management?

A.Use the time to have each developer read their completed tasks from the sprint backlog aloud while the Product Owner records attendance.

B.Present a detailed PowerPoint status report covering planned versus actual story points and ask stakeholders to sign off on the next sprint's scope.

C.Cancel the review and instead email stakeholders a link to the build so they can test it on their own time and reply with comments.

D.Demonstrate the working increment, invite stakeholders to explore it, and use their feedback to adapt the product backlog.

AnswerD

The Sprint Review is an inspect-and-adapt event centered on the working product increment. Demonstrating the increment and letting stakeholders interact with it produces concrete feedback that the Product Owner uses to update the product backlog. This collaborative, transparent approach embodies agile product management and keeps stakeholders engaged in shaping value rather than approving paperwork.

Why this answer

The Sprint Review is a collaborative inspect-and-adapt event where stakeholders examine the working increment and provide feedback that shapes the product backlog. Demonstrating the actual product and inviting hands-on exploration generates richer, more actionable input than any report. This keeps the focus on delivering value and ensures stakeholders participate in product direction rather than merely approving status.

Exam trap

The trap here is equating the Sprint Review with a traditional status meeting or slide-based sign-off instead of a working-product demonstration.

Practice this question →

11

Multi-Selectmedium

Which THREE of the following are essential for a good user story?

Select 3 answers

A.It is written in complex technical jargon.

B.It is independent of other stories.

C.It is thousands of pages long.

D.It provides clear value to the user.

E.It is small enough to be completed in one sprint.

AnswersB, D, E

Independence lets a story be developed, tested and accepted on its own, satisfying the INVEST criterion that prevents scheduling and prioritisation being blocked by another story's unfinished work. This decoupling reduces coordination overhead and enables the team to deliver value incrementally within an iteration.

Why this answer

Option B is correct because good user stories should be independent, meaning they can be developed, tested, and delivered without being tightly coupled to other stories, which supports flexible prioritization and reduces dependencies. Option D is correct because a user story must deliver clear value to the user or customer; this is the core purpose of a story and ensures the work is meaningful rather than purely technical. Option E is correct because a good user story should be small enough to be completed within a single sprint, aligning with the INVEST criteria's 'Small' principle and enabling reliable iteration planning.

Option A is incorrect because user stories should be written in plain, business-oriented language rather than complex technical jargon, so that stakeholders and developers can understand them. Option C is incorrect because user stories should be concise and short, not thousands of pages long; excessive length indicates poor decomposition and defeats the purpose of a lightweight requirements artifact.

Exam trap

PMI-ACP often tests the INVEST criteria, so the trap is choosing answers that sound like good engineering practice (technical detail, large documentation) but violate the user-value and small-size principles of good stories.

Practice this question →

12

MCQmedium

A product owner needs to show the long-term product roadmap to the board. What is the most appropriate format?

A.A detailed Gantt chart with fixed dates for every task.

B.A list of all team members and their assignments.

C.A high-level view showing themes and time horizons.

D.A printout of the entire product backlog.

AnswerC

A roadmap communicates direction, not delivery dates, so themes mapped against time horizons give the board a strategic view without implying fixed commitments. Detailed feature lists or sprint backlogs belong to release and iteration planning, which would misrepresent long-term uncertainty to executives.

Why this answer

An Agile product roadmap is a high-level, outcome-oriented view that communicates themes, epics, and time horizons (e.g., now/next/later or quarterly) rather than fixed dates and tasks. For a board audience, this format conveys strategic direction and adaptability while avoiding false precision. It aligns with Agile's empirical approach and allows for re-planning as market conditions change.

Exam trap

PMI-ACP often tests the distinction between Agile roadmaps (high-level, adaptive) and traditional Gantt charts (detailed, fixed)—candidates who default to 'detailed plan' answers fail because Agile values responding to change over following a plan.

How to eliminate wrong answers

Option A is wrong because a detailed Gantt chart with fixed dates for every task is a predictive/waterfall artifact that contradicts Agile planning and creates brittle commitments. Option B is wrong because listing team members and assignments is a resource plan, not a product roadmap, and provides no strategic product direction. Option D is wrong because printing the entire product backlog is tactical and overwhelming; the backlog is a living artifact for the team, not a board-level communication tool.

Practice this question →

13

MCQeasy

In the context of the product roadmap, what is the primary purpose of a release plan?

A.To replace the need for sprint planning.

B.To dictate the exact daily tasks for each developer.

C.To provide a high-level view of when features will be available.

D.To guarantee that all features will be completed on time.

AnswerC

A release plan translates roadmap items into scheduled increments, showing which features will be delivered in each upcoming release and roughly when. This satisfies the roadmap's need for a high-level timeline view, without committing to sprint-level detail that iteration planning handles.

Why this answer

A release plan provides a high-level view of when features or feature sets will be available to users, bridging the product roadmap and sprint execution. It communicates intended release dates and scope at a coarse granularity without committing to exact daily tasks. This helps stakeholders align on delivery expectations while preserving agile flexibility.

Exam trap

PMI-ACP often tests the misconception that a release plan is a fixed commitment or a replacement for sprint planning, when it is actually a high-level, adaptable forecast.

How to eliminate wrong answers

Option A is wrong because a release plan does not replace sprint planning; sprint planning operates at a finer granularity and is still required to determine how work will be done in each iteration. Option B is wrong because dictating exact daily tasks is micromanagement and is not the purpose of any agile planning artifact. Option D is wrong because a release plan is a forecast, not a guarantee—agile embraces uncertainty and welcomes changing requirements, so guaranteeing all features on time contradicts agile principles.

Practice this question →

14

Multi-Selecthard

Which THREE factors should influence the priority of a product backlog item?

Select 3 answers

A.The personal preference of the developers.

B.The font size of the story description.

C.Business value to the customer.

D.Cost of development.

E.Technical risk or uncertainty.

AnswersC, D, E

Business value to the customer is the primary prioritisation driver, since backlog ordering should maximise delivered value. Items yielding greater customer benefit or revenue are sequenced earlier, ensuring the team builds what stakeholders actually need first.

Why this answer

Option C (business value to the customer) is correct because backlog prioritization should maximize delivered value, so items that provide greater customer or business benefit are ranked higher. Option D (cost of development) is correct because the effort and resources required affect return on investment; a high-value item that is cheap to build may outrank an equally valuable but expensive one. Option E (technical risk or uncertainty) is correct because high-risk or uncertain items are often prioritized early to reduce unknowns, validate assumptions, and avoid costly late rework.

Option A is not a valid factor because prioritization must be based on value and risk rather than developers' personal preferences, and Option B is irrelevant since the visual formatting of a story description has no bearing on its business importance.

Exam trap

PMI-ACP often tests whether candidates can distinguish genuine prioritization factors from irrelevant or subjective criteria, and the trap is selecting developer preference or cosmetic details as valid inputs.

Practice this question →

15

MCQhard

An agile team is consistently failing to deliver the 'must-have' features by the release deadline. What should the Product Owner do?

A.Remove the Scrum Master for not pushing the team harder.

B.Mandate mandatory weekend work for the team.

C.Collaborate with stakeholders to re-negotiate scope or the release date.

D.Lower the quality standards to get it done faster.

AnswerC

The team cannot meet must-have commitments within the fixed release window, so the Product Owner must engage stakeholders to adjust either scope or the release date. This restores a deliverable commitment aligned with actual team velocity, rather than pressuring the team or silently dropping features.

Why this answer

When an agile team cannot deliver must-have features by the release deadline, the Product Owner's responsibility is to manage scope and stakeholder expectations, not to squeeze the team. Collaborating with stakeholders to re-negotiate scope or the release date respects the Agile principle of delivering value within sustainable pace and acknowledges that fixed scope, fixed date, and fixed quality cannot all be guaranteed simultaneously. This is the only option that addresses the root cause through transparent negotiation rather than coercion or quality compromise.

Exam trap

PMI-ACP often tests whether candidates default to command-and-control or quality-cutting responses under deadline pressure — the trap is choosing an option that 'gets it done' (overtime, lower quality) instead of the Agile-aligned negotiation and sustainable-pace response.

How to eliminate wrong answers

Option A is wrong because removing the Scrum Master misdiagnoses the problem — the Scrum Master facilitates the process and removes impediments, but the team's delivery shortfall is a scope/capacity issue, not a servant-leadership failure. Option B is wrong because mandating weekend work violates the Agile principle of sustainable development, degrades morale, increases defect rates, and is unsustainable — it treats a planning problem as an effort problem. Option D is wrong because lowering quality standards to hit a date directly contradicts the Agile emphasis on technical excellence and working software, and it accumulates technical debt that slows future delivery.

Practice this question →

16

MCQhard

An agile team is using 'Story Points' for estimation. Why is this preferred over 'Hours' for backlog items?

A.It is required by the project management office.

B.It makes it easier to track individual performance.

C.It accounts for complexity, effort, and uncertainty without needing precise time forecasting.

D.It ensures that every story takes exactly the same amount of time.

AnswerC

Story points rate relative size using a non-linear scale that folds in complexity, effort and uncertainty, so estimates need no precise time forecasting. Hours imply false precision and decay as team velocity changes, which is why points suit backlog estimation better.

Why this answer

Story points are a relative, unitless measure that captures complexity, effort, and uncertainty together, which is why they are preferred over hours for backlog estimation. Because humans are better at comparing items than forecasting absolute durations, relative sizing produces more reliable estimates and avoids false precision. Story points also decouple estimation from individual time tracking, supporting team-based planning.

Exam trap

The trap is treating story points as a disguised time unit, so candidates pick options about individual performance tracking or uniform duration instead of the relative, uncertainty-aware nature of points.

How to eliminate wrong answers

Option A is wrong because story points are not a PMO mandate; they are an Agile practice chosen for their estimation benefits, and imposing them as a compliance requirement misses the point. Option B is wrong because story points are deliberately not tied to individual performance; using them to track individuals corrupts the estimates and undermines team collaboration. Option D is wrong because story points do not make every story take the same time — they express relative size, and actual duration still varies with team capacity and context.

Practice this question →

17

MCQmedium

A product vision has become outdated due to market shifts. How should the Product Owner proceed?

A.Allow developers to decide the new vision.

B.Collaborate with stakeholders to revise the product vision.

C.Wait until the end of the project to change the vision.

D.Ignore the shift and continue with the original plan.

AnswerB

Revising the vision with stakeholders directly addresses the market shift by revalidating value against current customer needs. This collaborative approach satisfies the Product Owner's accountability for maximising value, ensuring the updated vision reflects stakeholder input rather than one person's assumptions, and realigns the backlog and roadmap with the changed market.

Why this answer

The product vision is owned by the Product Owner but shaped with stakeholders, so when market shifts invalidate it, the Product Owner should collaborate with stakeholders to revise it. This keeps the vision aligned with business value and customer needs while preserving stakeholder buy-in. The Product Owner remains accountable for the vision, but revising it is a collaborative, not unilateral, act.

Exam trap

The trap is confusing ownership with unilateral authority, so candidates pick 'let developers decide' or 'wait until the end' instead of the collaborative stakeholder revision the Product Owner role actually requires.

How to eliminate wrong answers

Option A is wrong because developers do not own the product vision; delegating it to them abdicates the Product Owner's accountability and bypasses stakeholder alignment. Option C is wrong because waiting until the end of the project to change the vision guarantees the team builds something the market no longer wants, wasting the entire investment. Option D is wrong because ignoring the market shift and continuing the original plan is the classic failure to embrace change, producing a product with no market fit.

Practice this question →

18

MCQhard

A customer feedback session reveals a major flaw in the current product design. What is the first thing the Product Owner should do?

A.Ignore the feedback if the project budget is depleted.

B.Blame the development team for the flaw.

C.Immediately delete the feature from the product.

D.Analyze the feedback and update the backlog to address the issue.

AnswerD

The Product Owner owns backlog ordering, so the immediate action is to analyse the feedback and reflect the identified flaw as backlog items, enabling the team to prioritise a fix. This keeps the response within the Product Owner's authority rather than escalating or redesigning directly.

Why this answer

The Product Owner is the sole person accountable for managing and ordering the product backlog, so the correct first response to significant customer feedback is to analyze it and reflect the findings in the backlog. This keeps the product aligned with customer value and allows the team to re-plan in the next refinement or sprint planning session. Deleting, ignoring, or blaming are all reactive behaviors that violate the PO's responsibility to maximize product value.

Exam trap

PMI-ACP often tests the misconception that a Product Owner should shield the team from bad news or make unilateral scope decisions; the trap is choosing an emotional or expedient action (ignore, blame, delete) instead of the disciplined backlog-management response.

How to eliminate wrong answers

Option A is wrong because ignoring valid customer feedback due to budget pressure abandons the PO's duty to maximize value and hides a real product risk rather than managing it. Option B is wrong because blaming the development team is a command-and-control, non-agile behavior that destroys trust and self-organization, and the PO owns backlog content, not the team's blame. Option C is wrong because immediately deleting the feature is an impulsive, unanalyzed decision that skips impact assessment, stakeholder input, and backlog refinement.

Practice this question →

19

MCQhard

A team has high velocity but the customer reports the product is not meeting their needs. What is the most likely cause?

A.The product backlog is not prioritized based on customer value.

B.The sprint duration is too short.

C.The team is lacking a project manager.

D.The team is not using enough automated tests.

AnswerA

High velocity with poor customer outcomes points to effort being spent on low-value items. Prioritising the product backlog by customer value ensures the team delivers the most valuable features first, directly addressing the mismatch between throughput and customer needs.

Why this answer

High velocity with poor customer satisfaction most likely indicates that the team is building the wrong things—the product backlog is not prioritized based on customer value. Velocity measures output, not outcome. If the backlog is not aligned with customer needs, the team can efficiently deliver features that miss the mark.

Exam trap

The trap is equating high velocity with success, causing candidates to overlook that velocity is an output metric and customer value is the true measure of success.

How to eliminate wrong answers

Option B is wrong because sprint duration affects cadence, not the relevance of the work; shorter sprints can improve feedback but do not cause misalignment. Option C is wrong because lacking a project manager is not inherently a problem in Agile, where the Product Owner and Scrum Master handle those responsibilities. Option D is wrong because insufficient automated tests affect quality and speed, not whether the product meets customer needs.

Practice this question →

20

Multi-Selecteasy

Which TWO methods are effective for gathering stakeholder feedback?

Select 2 answers

A.Observing users while they use the product.

B.Ignoring feedback to prevent scope creep.

C.Asking only one stakeholder for their opinion.

D.Conducting sprint reviews with stakeholders.

E.Sending a survey and never looking at the results.

AnswersA, D

Observation reveals actual usage patterns.

Why this answer

Option A is correct because direct observation of users interacting with the product (e.g., usability testing or contextual inquiry) yields firsthand, unbiased behavioral data about real pain points, workflows, and unmet needs that stakeholders may not articulate in words. Option D is correct because sprint reviews are a formal Scrum inspect-and-adapt event where the team demonstrates a potentially shippable Increment to stakeholders, who then provide structured feedback that feeds directly into the Product Backlog for the next Sprint. Option B is wrong because ignoring feedback does not prevent scope creep—it merely hides requirements and risks delivering a product that fails to meet stakeholder needs.

Option C is wrong because relying on a single stakeholder produces a biased, unrepresentative view and excludes other legitimate perspectives. Option E is wrong because collecting survey data without analyzing the results generates no actionable insight and wastes stakeholders' time.

Exam trap

PMI-ACP often tests the misconception that feedback can be gathered passively or from a single source, when effective feedback requires active engagement with multiple stakeholders through structured and observational methods.

Practice this question →

21

MCQhard

A project is mid-way, and stakeholders want to add a feature that was not in the original product roadmap. What is the appropriate response?

A.Evaluate the feature's value and impact on the backlog priority.

B.Reject the request because it was not in the roadmap.

C.Immediately add the feature to the current sprint.

D.Refer the request to the project manager for approval.

AnswerA

Agile teams handle unplanned requests by assessing the feature's business value and its effect on existing backlog priorities rather than automatically accepting or rejecting it. This lets the product owner reprioritise transparently, satisfying the stem's mid-project scope-change scenario.

Why this answer

In agile, the product backlog is emergent and can change as new information and stakeholder needs arise. The appropriate response to a mid-project feature request is to evaluate its value and impact on backlog priority, then let the product owner decide where it fits relative to existing items. This preserves the team's ability to deliver the highest-value work while remaining responsive to change.

Exam trap

PMI-ACP often tests the product owner's authority over backlog prioritization versus traditional project manager approval, so the trap is choosing 'refer to the project manager' or 'reject because not in roadmap' instead of evaluating value and re-prioritizing.

How to eliminate wrong answers

Option B is wrong because rejecting a request solely because it was not in the original roadmap contradicts agile's embrace of changing requirements and ignores the possibility that the feature adds significant value. Option C is wrong because immediately adding the feature to the current sprint bypasses backlog refinement, prioritization, and the team's capacity planning — it disrupts the sprint commitment and is not the product owner's decision alone. Option D is wrong because referring the request to a project manager for approval reflects a traditional command-and-control model; in agile, the product owner owns backlog prioritization and the team self-manages its work.

Practice this question →

22

MCQmedium

A team has too many competing priorities. Which framework helps them focus?

A.First-come, first-served based on email timestamps.

B.MoSCoW prioritization.

C.Random selection of tasks.

D.The 80/20 rule of project management.

AnswerB

MoSCoW sorts requirements into Must, Should, Could and Won't, forcing the team to agree which items are mandatory for the current timebox. This directly resolves competing priorities by making explicit what can be deferred, rather than treating every request as equally urgent.

Why this answer

MoSCoW prioritization is a widely used agile technique that categorizes requirements into Must have, Should have, Could have, and Won't have. It helps teams focus by explicitly agreeing on what is essential for the current delivery and what can be deferred, thereby reducing competing priorities. In PMI-ACP, MoSCoW is recognized as a simple, effective method for managing scope and ensuring stakeholder alignment on priority.

Exam trap

PMI-ACP often tests the confusion between general heuristics (like the 80/20 rule) and structured prioritization frameworks (like MoSCoW), so candidates may pick the 80/20 rule thinking it is a prioritization technique when it is merely a principle.

How to eliminate wrong answers

Option A is wrong because first-come, first-served based on email timestamps is an arbitrary and reactive approach that does not consider business value or urgency, and can lead to constant context switching. Option C is wrong because random selection of tasks ignores all prioritization criteria and is not a recognized framework; it would exacerbate the problem of competing priorities. Option D is wrong because the 80/20 rule (Pareto principle) is a general heuristic, not a prioritization framework; while it can inform decisions, it does not provide the structured categories needed to resolve conflicting priorities among stakeholders.

Practice this question →

23

Multi-Selecteasy

Which TWO of the following are benefits of maintaining a prioritized product backlog?

Select 2 answers

A.It allows the team to avoid all technical debt.

B.It guarantees that the project will finish on time.

C.It ensures the highest value items are addressed early.

D.It provides transparency to stakeholders on current priorities.

E.It eliminates the need for sprint planning.

AnswersC, D

Ordering the backlog by value places the highest-value items at the top, so the team delivers them in early iterations. This directly satisfies the benefit of addressing maximum business value first, rather than leaving valuable work until later sprints.

Why this answer

Option C is correct because a prioritized product backlog orders items by business value, risk, or dependency, so the highest-value work is pulled into early sprints and delivered sooner, maximizing return on investment. Option D is correct because the ordered backlog is a visible artifact that shows stakeholders exactly what the team plans to work on next and why, giving transparency into current priorities and enabling informed feedback. Options A, B, and E do not belong: a prioritized backlog cannot eliminate all technical debt (A), cannot guarantee on-time delivery since estimates and impediments still vary (B), and does not remove the need for sprint planning, where the team selects and decomposes backlog items into a sprint goal (E).

Exam trap

PMI-ACP often tests the difference between benefits and guarantees; the trap is selecting absolute claims like 'avoids all technical debt' or 'guarantees on-time delivery' instead of the realistic benefits of prioritization and transparency.

Practice this question →

24

MCQmedium

A stakeholder demands that a feature be completed by next week. The team identifies this as a high-risk task. What should the Product Owner do?

A.Discuss the risks with the stakeholder and negotiate the timeline or scope.

B.Force the team to work overtime to ensure completion.

C.Delegate the task to a junior developer to save costs.

D.Agree to the request to satisfy the stakeholder.

AnswerA

The Product Owner owns backlog prioritisation and value trade-offs, so addressing the stakeholder's fixed-date demand means surfacing the identified risk and negotiating either the timeline or the feature scope, rather than committing the team to an unachievable deadline.

Why this answer

When a stakeholder demands a high-risk feature on a tight timeline, the Product Owner should discuss the risks with the stakeholder and negotiate timeline or scope, because the PO is accountable for maximizing value while protecting the team's sustainable pace. This preserves transparency and allows informed trade-offs rather than committing to an unrealistic date. It also respects the team's self-management and the empirical nature of agile planning.

Exam trap

PMI-ACP often tests the misconception that a PO should always say yes to stakeholders; the trap is choosing compliance or heroics (overtime, delegation, blind agreement) instead of transparent negotiation and risk discussion.

How to eliminate wrong answers

Option B is wrong because forcing overtime violates sustainable pace, increases defect risk, and is a command-and-control response that undermines self-organization. Option C is wrong because delegating a high-risk task to a junior developer to save costs ignores skill fit and increases the likelihood of failure, which is poor risk management. Option D is wrong because agreeing to the request just to satisfy the stakeholder hides the risk, sets up the team for failure, and violates the PO's duty to be transparent about trade-offs.

Practice this question →

25

Multi-Selectmedium

Which THREE activities are part of product backlog refinement?

Select 3 answers

A.Conducting the daily stand-up meeting.

B.Re-ordering items based on current priorities.

C.Defining the product's annual budget.

D.Estimating the size of backlog items.

E.Adding detail to user stories.

AnswersB, D, E

Refinement continuously grooms the backlog, and re-ordering items by current business value or priority keeps the highest-value work at the top, ready for the next iteration. This is a core refinement activity alongside detailing and estimating.

Why this answer

Backlog refinement is the ongoing activity of reviewing and improving the product backlog, and re-ordering items based on current priorities (B) is a core part of it because the Product Owner continuously reprioritizes items so the most valuable work sits at the top for upcoming sprints. Estimating the size of backlog items (D) is also part of refinement, since the team assigns relative estimates (e.g., story points) to items so they can be planned and forecast effectively. Adding detail to user stories (E) is likewise correct, as refinement involves clarifying, splitting, and elaborating items with acceptance criteria so they are ready for a future sprint.

The daily stand-up (A) is a separate Scrum event for inspecting progress toward the sprint goal, not a refinement activity, and defining the product's annual budget (C) is a financial/portfolio activity outside the scope of backlog refinement.

Exam trap

PMI-ACP often tests the confusion between backlog refinement and other Scrum events — candidates incorrectly include the Daily Stand-up or Sprint Planning activities as refinement tasks.

Practice this question →

26

MCQhard

A team is struggling to keep their backlog refined. What is a sign of poor backlog refinement?

A.The team finishes all stories in the sprint.

B.The backlog is sorted by priority.

C.The product owner is involved in refinement.

D.The team frequently asks for clarification during the sprint.

AnswerD

Frequent mid-sprint clarification requests signal that stories lacked sufficient detail, acceptance criteria, or shared understanding when pulled. Effective refinement produces ready, unambiguous items, so recurring questions during the sprint indicate the backlog is not being adequately prepared ahead of time.

Why this answer

Frequent mid-sprint clarification requests signal that stories were not sufficiently refined—lacking clear acceptance criteria, dependencies, or shared understanding—before entering the sprint. Effective backlog refinement (grooming) ensures the team understands the 'what' and 'why' of upcoming stories, typically through the Definition of Ready. When the team constantly interrupts the PO during the sprint, it indicates refinement was superficial or skipped.

Exam trap

The trap is selecting an obviously positive-sounding option (A, B, or C) as the 'sign of poor refinement' because the question asks for a negative indicator—candidates must recognize that the correct answer describes a dysfunction, not a best practice.

How to eliminate wrong answers

Option A is wrong because finishing all stories in the sprint is a positive outcome and a sign of good planning and refinement, not a problem. Option B is wrong because a priority-sorted backlog is a best practice and evidence of healthy refinement. Option C is wrong because PO involvement in refinement is essential and expected, not a sign of poor refinement.

Practice this question →

27

Multi-Selecteasy

Which THREE items are typically included in a user story?

Select 3 answers

A.Business value/benefit.

B.User role.

C.Complete database schema.

D.Desired functionality.

E.The full source code of the feature.

AnswersA, B, D

Business value states the benefit a story delivers, letting the team prioritise by customer impact rather than technical effort. It satisfies the stem's requirement for a typical user story component, alongside the role and goal. This makes it a standard element in PMI-ACP story formatting.

Why this answer

A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, so it typically includes the user role (option B), which identifies who wants the functionality (e.g., 'As a [role]'). It also includes the desired functionality (option D), which states what the user wants to accomplish (e.g., 'I want [feature]'), and the business value/benefit (option A), which explains why the feature matters (e.g., 'so that [benefit]'). These three elements form the classic 'As a <role>, I want <functionality>, so that <benefit>' template.

Options C and E are not part of a user story: a complete database schema is a technical design artifact, and full source code is an implementation detail, both of which are far too detailed and belong to later development phases, not to the user story itself.

Exam trap

PMI-ACP often tests the distinction between user stories and technical specifications, so candidates may mistakenly select database schema or source code as part of a user story, confusing requirements with design artifacts.

Practice this question →

28

MCQmedium

A user story lacks specific acceptance criteria. What is the risk to the development team?

A.The team will not know when the story meets requirements.

B.The sprint will end earlier than expected.

C.The velocity will artificially increase.

D.The story will be too small to estimate.

AnswerA

Without acceptance criteria, the team cannot verify completion, so the story's definition of done stays ambiguous. This directly satisfies the stem's constraint: absent testable conditions, developers cannot determine whether the increment meets the product owner's requirements, risking rework, scope creep and disputed sign-off during the iteration review.

Why this answer

Acceptance criteria define the conditions a story must satisfy to be considered done, so without them the team has no objective way to know when the work is complete or whether it meets the user's needs. This ambiguity leads to rework, scope disputes, and stories that pass code review but fail acceptance because 'done' was never defined.

Exam trap

The trap is picking an answer about velocity or sprint duration — PMI-ACP wants candidates to recognize that acceptance criteria are about defining 'done' and preventing rework, not about estimation or sprint mechanics.

How to eliminate wrong answers

Option B is wrong because missing acceptance criteria don't shorten a sprint — they typically extend it through rework and clarification cycles, not truncate it. Option C is wrong because velocity doesn't artificially increase from missing criteria; if anything, it becomes unreliable because 'done' is undefined and stories may be counted as complete prematurely. Option D is wrong because acceptance criteria are about defining completion, not about story size — a story can be small and still lack clear criteria, and size is estimated separately using story points or similar techniques.

Practice this question →

29

MCQeasy

Which persona is primarily responsible for ensuring the product backlog reflects the needs of the stakeholders and customers?

A.The Project Sponsor.

B.The Scrum Master.

C.The Product Owner.

D.The Lead Developer.

AnswerC

The Product Owner owns and orders the product backlog, translating stakeholder and customer needs into prioritised items the team delivers. This makes that persona primarily accountable for ensuring the backlog reflects those needs, as the stem requires.

Why this answer

The Product Owner is the single persona accountable for maximizing product value and ensuring the product backlog reflects stakeholder and customer needs. In Scrum and agile practice, the PO owns backlog content, ordering, and refinement. This role is explicitly defined in the Scrum Guide and PMI-ACP materials as the voice of the customer.

Exam trap

PMI-ACP often tests role confusion, tempting candidates to assign backlog ownership to the Scrum Master or Sponsor instead of the Product Owner.

How to eliminate wrong answers

Option A is wrong because the Project Sponsor provides funding and high-level support but does not own or shape the product backlog. Option B is wrong because the Scrum Master is a servant leader who facilitates process and removes impediments, not the owner of backlog content. Option D is wrong because the Lead Developer contributes technical input but does not have accountability for representing stakeholder and customer needs in the backlog.

Practice this question →

30

MCQmedium

During a sprint planning session, the team realizes a user story is too large to complete in one sprint. What is the most effective approach to handle this?

A.Decompose the story into smaller, independently deliverable user stories.

B.Mark the story as blocked and move to the next sprint.

C.Extend the sprint duration to accommodate the story size.

D.Ask the developers to work overtime to finish it.

AnswerA

Splitting the oversized story into smaller, independently deliverable slices lets the team finish work within a single sprint, satisfying the sprint timebox constraint. Each slice can be estimated, prioritised and accepted separately, preserving incremental value delivery rather than carrying an incomplete story across sprints.

Why this answer

Decomposing the story into smaller, independently deliverable user stories is correct because it allows the team to complete valuable increments within the sprint, maintains flow, and adheres to the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). This approach enables continuous delivery and reduces batch size, which is a core Agile principle.

Exam trap

PMI-ACP often tests the misconception that large stories should be deferred or that overtime is acceptable; the correct answer is almost always to split the story into smaller, valuable increments.

How to eliminate wrong answers

Option B is wrong because marking the story as blocked and moving it to the next sprint delays value delivery and ignores the opportunity to split the work into manageable pieces. Option C is wrong because extending the sprint duration violates the timebox principle and disrupts cadence and predictability. Option D is wrong because asking developers to work overtime is unsustainable, reduces quality, and contradicts Agile's emphasis on sustainable pace.

Practice this question →

31

MCQmedium

A product team is six sprints into a new product. The Product Owner has been ordering the product backlog strictly by business value, but the team keeps discovering late that some high-value features are technically infeasible. What should the Product Owner do to improve the ordering of the product backlog?

A.Move all technically complex items to the bottom of the backlog permanently so the team only works on simple, low-risk features.

B.Ask the team to stop raising feasibility concerns and commit to the highest-value items first, since the Product Owner owns backlog ordering.

C.Include the team's technical feasibility assessment and effort estimates when ordering the backlog, balancing value against risk and cost of delay.

D.Have the team create a separate technical backlog that the Product Owner is not allowed to see or prioritize.

AnswerC

Ordering the product backlog is a Product Owner accountability, but it should not be done on business value alone. Incorporating the team's technical feasibility input and relative effort estimates lets the Product Owner weigh value against risk and cost of delay, so high-value but infeasible items are surfaced early rather than discovered late in a sprint.

Why this answer

Product backlog ordering is a Product Owner accountability, but effective ordering requires collaboration with the team that provides feasibility and effort information. By combining business value with technical risk and cost of delay, the Product Owner can sequence items so that uncertain or infeasible high-value features are explored early. This reduces late surprises and keeps the backlog a living, transparent artifact that reflects both value and technical reality.

Exam trap

The trap here is assuming that because the Product Owner owns backlog ordering, value alone should drive the sequence and the team's technical input is optional.

Practice this question →

32

MCQhard

A team is working on a legacy product. How should the Product Owner balance new feature requests with maintenance?

A.Devote 100% of capacity to new features.

B.Allocate a fixed percentage of capacity to maintenance and technical debt.

C.Only perform maintenance during the weekends.

D.Only prioritize maintenance when the system fails.

AnswerB

Allocating a fixed percentage of capacity to maintenance and technical debt ensures the legacy product remains stable while new features progress. This directly satisfies the constraint of balancing both demands sustainably, preventing technical debt from overwhelming future delivery. The Product Owner reserves capacity each iteration, making maintenance a predictable, ongoing commitment rather than a reactive afterthought.

Why this answer

On a legacy product, the Product Owner should explicitly reserve a portion of each iteration's capacity for maintenance and technical debt so the system remains stable and evolvable while new features are delivered. This is a deliberate, transparent trade-off rather than an all-or-nothing choice. It reflects the agile principle of sustainable pace and the reality that technical debt compounds if ignored.

Exam trap

PMI-ACP often tests the false dichotomy that a PO must choose between features and maintenance; the trap is selecting an extreme option (100% features, weekends only, or fix-on-failure) instead of the balanced, planned capacity allocation that agile economics recommends.

How to eliminate wrong answers

Option A is wrong because devoting 100% of capacity to new features starves maintenance, causing technical debt to accumulate until the legacy system becomes unstable or unmaintainable. Option C is wrong because restricting maintenance to weekends violates sustainable pace, creates burnout, and treats maintenance as an afterthought rather than planned work. Option D is wrong because only reacting when the system fails is purely reactive firefighting, which is far more costly and risky than proactively allocating capacity to known maintenance needs.

Practice this question →

33

MCQhard

A product team is using a Kanban board to manage a continuous flow of feature requests. The Product Owner wants to limit work in progress (WIP) to improve cycle time but is unsure which column should have the strictest WIP limit. The team's workflow is: Backlog -> Analysis -> Development -> Testing -> Done. Where should the strictest WIP limit typically be applied, and why?

A.Backlog, because too many items waiting creates unrealistic expectations.

B.Testing, because it is often the bottleneck where work accumulates and limits flow.

C.Development, because it is usually the longest and most resource-intensive stage.

D.Done, because completed items should be removed quickly to free capacity.

AnswerB

This is correct because WIP limits should be strictest at the bottleneck to prevent excessive queue buildup and improve flow. In many software teams, Testing becomes the constraint due to specialized skills or environment constraints. By capping Testing WIP, the team exposes the bottleneck, encourages swarming, and reduces cycle time. The limit is not arbitrary but based on observed flow.

Why this answer

In Kanban, WIP limits are most effective when applied to the bottleneck to prevent queue buildup and improve flow. Testing is frequently the bottleneck in software teams due to environment setup, specialized testers, or rework. A strict WIP limit there forces the team to swarm on testing, reduces multitasking, and shortens cycle time.

The correct answer reflects the flow-based principle of managing the constraint.

Exam trap

The trap here is assuming a fixed stage always needs the strictest limit, rather than identifying the actual bottleneck through flow metrics.

Practice this question →

34

MCQeasy

When writing user stories, which criteria ensure the story is ready for the development team to estimate?

A.The story must be at least 10 pages long.

B.The story must meet the Definition of Ready.

C.The story must be approved by the CEO.

D.The story must be assigned to a specific developer.

AnswerB

The Definition of Ready is the agreed checklist confirming a story is sufficiently refined, estimated and understood before sprint planning. Meeting it signals the team has enough detail to size the work, which is the criterion the question asks for.

Why this answer

The Definition of Ready (DoR) is an agile team's explicit checklist that a user story must satisfy before it can be pulled into a sprint for estimation and development. It typically covers INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable), acceptance criteria being defined, dependencies identified, and the story being small enough to complete in one iteration. Meeting the DoR is the agreed signal that the team has enough shared understanding to size the work reliably.

Exam trap

PMI-ACP often tests the confusion between traditional gatekeeping (management approval, detailed documentation, individual assignment) and agile readiness signals like the Definition of Ready, so candidates who default to command-and-control assumptions pick C or D.

How to eliminate wrong answers

Option A is wrong because user stories are intentionally short, conversational descriptions of value — length is not a readiness criterion, and a 10-page document contradicts the agile principle of 'working software over comprehensive documentation.' Option C is wrong because executive approval is not part of any agile readiness framework; the Product Owner prioritizes the backlog, and the team self-manages estimation, so CEO sign-off would create a bottleneck and violate self-organization. Option D is wrong because assigning a story to a specific developer before estimation undermines collective ownership and team-based estimation; in Scrum and most agile methods, work is pulled by the team, not pre-assigned to individuals.

Practice this question →

35

MCQmedium

Which of the following is an effective technique for eliciting requirements from stakeholders?

A.Building the entire product first and asking for feedback later.

B.Guessing the requirements based on past projects.

C.Waiting for the stakeholders to send an email.

D.Conducting user interviews or focus groups.

AnswerD

User interviews and focus groups elicit requirements directly from stakeholders, capturing needs, expectations, and context that documents alone miss. This satisfies the stem's requirement for an effective elicitation technique by enabling dialogue, clarification, and immediate follow-up questioning.

Why this answer

Conducting user interviews or focus groups is a direct, interactive elicitation technique that draws requirements straight from stakeholders through structured conversation, allowing the analyst to probe, clarify, and uncover latent needs. PMI-ACP and the Agile Manifesto emphasize 'individuals and interactions over processes and tools,' so face-to-face techniques like interviews and focus groups align with agile values. These methods produce rich, high-quality information that can be validated immediately with the stakeholder.

Exam trap

PMI-ACP often tests the distinction between active elicitation techniques (interviews, focus groups, workshops) and passive or deferred approaches (waiting for emails, building first, guessing), so candidates must recognize that agile values proactive collaboration.

How to eliminate wrong answers

Option A is wrong because building the entire product before gathering feedback is the antithesis of iterative development and guarantees expensive rework when requirements are wrong. Option B is wrong because guessing requirements from past projects ignores the current stakeholders' unique context and violates the principle of customer collaboration. Option C is wrong because passively waiting for an email is a push-based, reactive approach that does not actively elicit requirements and often yields incomplete or ambiguous information.

Practice this question →

36

Multi-Selectmedium

A Product Owner is preparing a product roadmap for a new SaaS platform. Stakeholders have conflicting priorities: sales wants custom features for a large client, while engineering wants to reduce technical debt. Which TWO actions best align with agile product management principles to balance these competing demands? (Choose two.)

Select 2 answers

A.Ask the engineering team to work overtime for several sprints to deliver both custom features and technical debt fixes.

B.Commit to delivering all custom features for the large client in the next sprint to secure the contract.

C.Escalate the conflict to senior management and ask them to decide the priority order for the Product Owner.

D.Prioritize backlog items based on customer value, risk, and dependency, and make the prioritization transparent to stakeholders.

E.Allocate a fixed percentage of each sprint's capacity to technical debt reduction, and treat it as a first-class backlog item.

AnswersD, E

This is correct because agile product management emphasizes value-driven prioritization that considers multiple factors. Making the process transparent helps stakeholders understand trade-offs and reduces conflict. It also allows the Product Owner to justify decisions with data rather than politics. This approach aligns with the PMI-ACP principle of delivering value continuously while managing stakeholder expectations.

Why this answer

Balancing competing demands requires value-based prioritization and explicit capacity allocation for technical debt. Transparent prioritization helps stakeholders see trade-offs, while dedicating capacity to debt prevents its accumulation. Together, these actions align with agile principles of delivering value sustainably and managing stakeholders collaboratively.

They also empower the Product Owner to make informed decisions without overcommitting the team.

Exam trap

The trap here is thinking that satisfying the loudest stakeholder immediately or escalating every conflict is effective product management, rather than using transparent value-based trade-offs.

Practice this question →

37

MCQeasy

Which document acts as the single source of truth for all work to be performed by the development team?

A.The sprint burndown chart.

B.The communication plan.

C.The project charter.

D.The product backlog.

AnswerD

The product backlog is the single source of truth for all work the development team performs, holding every feature, enhancement and fix in priority order. It satisfies the stem's requirement by centralising scope that the team pulls into sprints.

Why this answer

The product backlog is the single source of truth for all work the development team may perform. It is a prioritized, ordered list of everything that might be needed in the product, owned by the Product Owner and refined continuously. In Scrum and most Agile frameworks, the sprint backlog is derived from the product backlog, and no work should be done that is not represented there.

Exam trap

PMI-ACP often tests the distinction between the product backlog (all potential work) and the sprint backlog (committed work for one sprint), causing candidates to confuse the two or pick the charter as the overarching document.

How to eliminate wrong answers

Option A is wrong because the sprint burndown chart is a visualization of remaining work within a single sprint, not a comprehensive list of all work to be performed. Option B is wrong because the communication plan describes how information will be shared among stakeholders, not what work the team will do. Option C is wrong because the project charter authorizes the project and defines high-level scope and objectives, but it is not the working list of deliverables the team pulls from.

Practice this question →

38

MCQeasy

A Product Owner notices that the product backlog has grown significantly, making it difficult to find relevant work items. Which action should the Product Owner take to improve visibility?

A.Group related user stories under larger epics.

B.Archive the entire backlog and start a new one.

C.Increase the number of items per page in the tool.

D.Delete all old user stories to clear the clutter.

AnswerA

Grouping related user stories under larger epics reduces backlog clutter by creating a hierarchical structure, so the Product Owner can navigate themes rather than scanning every item. This directly satisfies the stem's visibility constraint, since epics act as parent containers that collapse detailed stories, making relevant work items easier to locate as the backlog grows.

Why this answer

Grouping related user stories under larger epics improves backlog visibility by creating a hierarchical structure that reduces clutter while preserving detail at the story level. This is a standard backlog refinement technique that helps the Product Owner and team navigate large backlogs. It maintains traceability from high-level themes to granular work items.

Exam trap

PMI-ACP often tests the misconception that backlog problems are solved by tool settings or wholesale deletion; the trap is choosing a destructive or cosmetic action instead of the structural refinement technique of grouping stories under epics.

How to eliminate wrong answers

Option B is wrong because archiving the entire backlog and starting a new one destroys historical context, traceability, and potentially valuable deferred work, and it does not solve the underlying organization problem. Option C is wrong because increasing items per page is a cosmetic UI change that does not improve logical structure or findability of relevant work. Option D is wrong because deleting old user stories removes potentially valuable backlog items and loses the rationale and history that support future prioritization decisions.

Practice this question →

39

MCQmedium

A Scrum team is building a mobile banking app. The Product Owner has a product backlog with 120 items, but the team often complains that the highest-priority items are too vague to estimate. Which action best applies the principle of progressive elaboration to improve the backlog?

A.Break down the top 10-15 backlog items into smaller, detailed stories with acceptance criteria, while leaving lower-priority items coarse.

B.Ask the team to estimate all 120 items in a single two-day estimation workshop to create a complete baseline.

C.Delegate all backlog refinement to a business analyst and have the team only review finalized stories at sprint planning.

D.Create a detailed Gantt chart mapping all 120 backlog items to specific sprints over the next 18 months.

AnswerA

This is correct because progressive elaboration means adding detail to backlog items just in time, based on priority. The team needs enough clarity for near-term work, so refining the top items into smaller stories with clear acceptance criteria directly addresses their complaint. Lower-priority items can remain coarse until they move up, avoiding wasted effort. This balances planning with agility.

Why this answer

Progressive elaboration means elaborating backlog items at the last responsible moment, focusing detail on what is near-term. Refining the top items into smaller stories with acceptance criteria gives the team enough information to estimate and plan upcoming sprints. Leaving lower-priority items coarse avoids wasted analysis.

This approach directly resolves the team's complaint while preserving agility.

Exam trap

The trap here is confusing progressive elaboration with upfront detailed planning of the entire backlog, which feels thorough but undermines agility.

Practice this question →

40

Multi-Selecthard

A Product Owner is refining a product backlog and wants to apply good agile product management practices to maximize value delivery. Which TWO actions best support effective product backlog management? (Choose two.)

Select 2 answers

A.Assign every backlog item a fixed delivery date at the start of the product and refuse to reorder regardless of new learning.

B.Continuously order backlog items by value, risk, dependencies, and cost of delay rather than freezing the sequence at project start.

C.Collaborate with the team during refinement to add detail, estimate effort, and split large items just in time for upcoming work.

D.Fully detail every backlog item to the same depth at the start of the product so the team never needs to refine again.

E.Keep the product backlog private to the Product Owner so the team and stakeholders cannot see items that may change.

AnswersB, C

Effective product backlog management requires continuous ordering that reflects current value, risk, dependencies, and cost of delay. Freezing the sequence at project start ignores learning and market change, so the backlog becomes stale. Revisiting the order frequently keeps the team working on the most economically important items and lets the Product Owner respond to new information as the product evolves.

Why this answer

Effective product backlog management rests on continuous ordering that reflects value, risk, dependencies, and cost of delay, combined with just-in-time collaborative refinement. Together these practices keep the most important items ready and economically sequenced while avoiding wasted upfront detail. Transparency and willingness to reorder based on learning are implicit in both actions, ensuring the backlog remains a living tool for maximizing product value.

Exam trap

The trap here is assuming thorough upfront detail and fixed sequencing make backlog management rigorous, when they actually destroy agility and waste effort.

Practice this question →

41

MCQeasy

What is the primary role of the 'Definition of Done' (DoD)?

A.To list the team members on the project.

B.To describe the user's requirements for the product.

C.To define the budget limit for the project.

D.To ensure a common understanding of quality and completeness for all work items.

AnswerD

The Definition of Done establishes a shared quality bar, so every increment meeting it is genuinely complete. This directly satisfies the stem's requirement for common understanding of quality and completeness across all work items, preventing differing interpretations between developers and stakeholders.

Why this answer

The Definition of Done is a shared, explicit checklist that determines when a product increment is complete and of acceptable quality. It creates a common understanding across the team, PO, and stakeholders of what 'done' means for every backlog item, preventing ambiguity about quality and completeness. Without a DoD, 'done' becomes subjective and technical debt accumulates.

Exam trap

The trap here is confusing the Definition of Done (quality/completeness standard) with acceptance criteria (specific functional requirements for a single story) — candidates often pick the requirements-based answer.

How to eliminate wrong answers

Option A is wrong because listing team members is a team roster or resource plan, not a quality/completeness agreement. Option B is wrong because user requirements are captured in user stories, acceptance criteria, or the product backlog — the DoD is about quality standards, not functional requirements. Option C is wrong because budget limits belong to financial planning or the project charter, not the DoD, which governs work item completion criteria.

Practice this question →

42

MCQhard

An organization is transitioning from project-based funding to product-based funding. How does this impact the Product Owner's role?

A.The Product Owner is now responsible for the annual budget.

B.The Product Owner no longer manages the backlog.

C.The Product Owner focuses on long-term product value rather than project milestones.

D.The Product Owner now reports to the finance department.

AnswerC

Product-based funding shifts investment toward sustained outcomes instead of fixed project scope and deadlines. The Product Owner therefore prioritises maximising long-term product value and continuous discovery, rather than tracking delivery against project milestones and temporary team assignments.

Why this answer

Moving from project-based to product-based funding shifts the Product Owner's focus from delivering against fixed project milestones and budgets to maximizing long-term product value and outcomes. Funding becomes continuous and tied to product strategy, so the PO prioritizes the backlog around value streams, customer outcomes, and lifecycle economics rather than one-time project completion.

Exam trap

PMI-ACP often tests the misconception that a funding model change alters the PO's core accountabilities, tempting candidates to pick options that reassign backlog ownership or budget responsibility instead of recognizing the shift toward long-term value focus.

How to eliminate wrong answers

Option A is wrong because budget ownership typically remains with finance, portfolio, or product leadership; the PO influences investment through value-based prioritization, not by owning the annual budget. Option B is wrong because backlog management is the core, non-negotiable accountability of the Product Owner in Scrum and is unaffected by the funding model. Option D is wrong because reporting lines are organizational and not dictated by the funding model; the PO remains accountable to the product's stakeholders and customers, not to finance.

Practice this question →

43

MCQmedium

A Product Owner notices that a user story describing an online checkout flow is too large to complete in a single sprint and keeps getting partially done. What is the most appropriate agile action to improve product flow?

A.Allow the team to carry the partially completed checkout story into the next sprint and count it toward that sprint's goal.

B.Ask the developers to work overtime to complete the full checkout story within the current sprint without changing its scope.

C.Split the story into smaller, independently valuable slices that each satisfy the Definition of Done within a sprint.

D.Extend the sprint length from two weeks to four weeks so the team has more time to finish the large checkout story.

AnswerC

Splitting a large story into smaller vertical slices that each meet the Definition of Done improves flow, enables frequent integration, and produces potentially releasable value each sprint. This practice, often called story slicing, keeps the product backlog actionable and lets the team finish work rather than carrying partial stories, which directly addresses the recurring incomplete checkout story.

Why this answer

Oversized stories that cannot meet the Definition of Done within a sprint disrupt flow and hide progress. Slicing them into smaller vertical increments, each independently valuable and completable within the timebox, restores predictable delivery and frequent feedback. This keeps the product backlog healthy and aligns with agile principles of small batches, sustainable pace, and potentially releasable increments.

Exam trap

The trap here is treating a story-sizing problem as a scheduling or effort problem by extending the sprint or adding overtime.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Product questions.

Start 20-question session