Try 10 focused PMI-ACP questions on Leadership, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PMI-ACP |
| Topic area | Leadership |
| Blueprint weight | 25% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Leadership for PMI-ACP. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 25% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
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.
Topic: Leadership
Two agile teams are building adjacent services on the same platform. A production incident revealed that Team B didn’t understand a key design decision in Team A’s service, causing rework and delays. Leaders want to encourage cross-team sharing of both technical and product knowledge without adding heavy process or slowing delivery.
Which action best optimizes knowledge sharing while respecting these constraints?
Best answer: B
What this tests: Leadership
Explanation: A cross-team community of practice with rotating demos and Q&A creates a low-friction, repeatable learning loop that spreads both technical decisions and product intent. It supports direct collaboration and shared understanding while keeping overhead small. This improves flow by preventing knowledge gaps from turning into rework.
To encourage cross-team sharing, prefer lightweight, frequent interactions that make knowledge visible and easy to pull, rather than relying on heavy documentation or single points of contact. A recurring cross-team community of practice (or shared demo/Q&A cadence) creates a regular space to surface architecture choices, product tradeoffs, and upcoming changes so adjacent teams can align early. Rotating facilitation and short show-and-tell segments keep it sustainable and reduce dependency on specific individuals.
Practical elements include:
The key takeaway is to build a repeatable, low-waste feedback and learning loop across teams.
A lightweight, recurring forum creates a pull-based habit of sharing context and decisions across teams with minimal overhead.
Topic: Leadership
An agile team is missing iteration goals and tension is rising between engineering and UX. Their board shows growing WIP and partially done work across many epics. In reviews, stakeholders attend regularly but often ask to “build it the other way,” creating rework.
The product vision is “cut customer onboarding time by 30% this quarter,” but the roadmap is a long list of detailed screens, workflows, and technical approach decisions, and most items are marked “high priority.”
What is the most likely underlying cause?
Best answer: C
What this tests: Leadership
Explanation: The clues point to poor translation of an outcome-based vision into a prioritized backlog. When the backlog is dominated by detailed solution decisions and everything is “high priority,” teams start too much work, debate designs, and churn based on feedback. The underlying issue is lack of outcome-focused prioritization and leaving solution space for the team to discover.
The core concept is translating a shared vision (outcome) into a prioritized roadmap/backlog without locking in the solution. Here, the vision is clear (“reduce onboarding time by 30%”), but the roadmap is packed with detailed screens and technical decisions and has little meaningful prioritization. That creates competing “must-do” work, pushes the team into parallel execution (growing WIP), and invites opinion-driven changes in reviews (rework and conflict) because the team is optimizing local designs instead of validating which slices best achieve the outcome.
A better translation is to:
The key takeaway is that over-specifying solutions and flattening priorities undermines focus, flow, and alignment to the vision.
Over-specified, solution-prescriptive items with unclear value ordering drive thrash, parallel work, and rework despite frequent stakeholder feedback.
Topic: Leadership
A product team has had the same type of defect escape to production in the last two iterations: a change passes manual testing but breaks an existing workflow. In the retrospective, the team notes they often skip regression checks when they feel pressure to meet the iteration goal, and their definition of done is vague about testing.
As the agile leader, what action best optimizes preventing recurrence while minimizing avoidable waste?
Best answer: B
What this tests: Leadership
Explanation: To prevent recurrence, the most effective lever is changing the team’s system of work so the risky behavior is no longer optional under pressure. Strengthening the definition of done to include automated regression checks and peer review makes quality explicit, repeatable, and visible, improving outcomes without adding a separate bureaucracy.
Recurring escaped defects are usually a system problem, not a one-time mistake. Here, the team explicitly says regression is skipped under schedule pressure and the definition of done is vague, so the highest-leverage fix is to adjust quality practices and working agreements so the desired behavior happens reliably.
A practical approach is to:
This improves quality and learning while preserving flow; adding external gates or separate phases tends to increase delays and handoffs without addressing why regression gets skipped.
Tightening the DoD and working agreement builds in a repeatable quality control that prevents the same escape defect pattern.
Topic: Leadership
A cross-functional agile team’s last two iterations missed their sprint goals due to frequent mid-sprint work interruptions and unclear handoffs. Tension is rising between development and operations.
You are facilitating a 60-minute problem-solving session and need it to end with a clear, owned action plan the team can start next iteration. What should you do to best optimize the outcome within the time constraint?
Best answer: B
What this tests: Leadership
Explanation: A problem-solving session is successful when it produces actionable, team-owned next steps. Using a lightweight root-cause approach aligns the group on what’s actually driving interruptions and handoff issues, then converges on a small number of experiments. Adding owners, due dates, and a check point turns ideas into an executable action plan within 60 minutes.
To facilitate problem resolution and end with a clear action plan, optimize for alignment plus actionability. Start by framing the problem and desired outcome, then use a quick root-cause technique (for example, 5 Whys or a cause-and-effect brainstorm) to avoid solving the wrong problem. Converge with a fast prioritization method and translate the selected improvements into experiments that are small enough to run next iteration.
A practical flow in 60 minutes is:
This preserves flow and learning while producing concrete, accountable next steps rather than mandates or escalation.
It creates shared understanding of the problem and converts it into a small set of testable actions with clear ownership and follow-up.
Topic: Leadership
An agile team has missed its iteration goal three times in a row. Their WIP has grown from 8 items to 19, and rework is increasing due to late defect discovery. Tension is rising, and team members avoid proposing spikes or trying new approaches.
In recent reviews and retrospectives, a manager repeatedly asks “Who caused this?” and has singled out individuals when an experiment didn’t work. The team now seeks approval for even small changes before acting.
What is the most likely underlying cause?
Best answer: D
What this tests: Leadership
Explanation: The key clue is the manager’s repeated blame and singling out people when experiments fail. That behavior reduces psychological safety, so the team stops taking responsible risks, delays learning, and adds approval gates—leading to growing WIP, more rework, and conflict. The root issue is a culture that punishes learning rather than enabling safe-to-fail experimentation.
Responsible risk-taking in agile depends on psychological safety: people must be able to surface problems early and run small experiments without fear of punishment. The stem’s strongest diagnostic clue is the manager asking “Who caused this?” and publicly calling out individuals when an experiment fails. That creates a blame culture, so the team shifts to “safe” work, seeks permission for minor changes, and avoids spikes—reducing learning and increasing big-batch work. These behaviors commonly show up as growing WIP, late quality discovery and rework, and interpersonal conflict.
A leadership fix is to model blameless learning (focus on system causes), encourage small safe-to-fail experiments with clear hypotheses, and treat outcomes as feedback rather than a basis for punishment.
Publicly blaming individuals for outcomes makes experimentation feel unsafe, driving approval-seeking behavior, conflict, and worsening flow/quality signals.
Topic: Leadership
You are coaching an agile team that is missing its iteration goal. Review the following artifact.
Exhibit: Board snapshot (today)
WIP limit (In Progress): 5
In Progress (5): all assigned to Alex
Code Review (4): 3 cards tagged "Waiting for Alex"
Done (today): 1 card (Alex)
To Do (3): 2 cards unassigned
Team comment: "Alex is the go-to to save the sprint"
What is the best next action to promote collective ownership of outcomes?
Best answer: C
What this tests: Leadership
Explanation: The exhibit shows flow constrained by one person: all WIP is with Alex and reviews are waiting on Alex. The best action is to facilitate team-level ownership by swarming on the highest-value items and sharing review/testing responsibilities so progress is not dependent on a single “hero.”
Collective ownership means the team owns the outcome (meeting the iteration goal with quality), not an individual owning tasks or being the single path to “done.” The board shows an explicit bottleneck: work and reviews are queued behind Alex, while other work remains unassigned. The best next action is to coach the team to change how they collaborate so finishing work becomes a shared activity.
This builds resilience and throughput, whereas relying on a hero reinforces dependency and recurring delays.
It removes the Alex bottleneck by shifting work completion and quality activities to the whole team.
Topic: Leadership
Two senior developers on an agile team are in a heated conflict about an API design. Both care about product quality, but the discussion has become personal and is starting to divide the team. As the agile practitioner facilitating, which approach best fits resolving the conflict while preserving relationships?
Best answer: A
What this tests: Leadership
Explanation: A collaborative, interest-based facilitation approach addresses the underlying interests (quality, maintainability, risk) rather than positions, which reduces defensiveness and helps people feel heard. It aims for a win-win outcome and strengthens trust, making it well suited to resolving conflict without damaging working relationships.
When conflict becomes personal, a relationship-preserving approach is to facilitate collaboration: separate people from the problem, uncover underlying interests, and jointly generate options that satisfy shared goals. In agile environments this is reinforced by servant leadership and facilitation that improves communication and alignment, rather than “winning” the argument.
A practical pattern is:
This keeps accountability with the team while reducing interpersonal harm; escalation or voting may end the debate but often leaves resentment or a “winner/loser” dynamic.
This uses a win-win, interest-based approach that focuses on shared goals and joint problem solving, protecting relationships while reaching agreement.
Topic: Leadership
An agile team has introduced knowledge-sharing practices (pairing rotations, short internal demos, and a shared troubleshooting wiki) to reduce delays when specialists are absent. After six weeks, a manager asks how to verify the practices are improving delivery outcomes.
Which technique best measures whether knowledge sharing is improving quality, speed, or consistency?
Best answer: B
What this tests: Leadership
Explanation: Use outcome metrics that reflect the intended impact of knowledge sharing: faster flow, fewer defects/rework, and reduced variability when work shifts between people. Comparing trends and variation in cycle time and defect measures before and after introducing the practices provides evidence of improvement beyond simple activity counts.
To verify knowledge sharing is helping, measure outcomes that should change if the team is less dependent on individuals: speed (lead/cycle time), quality (defects, escaped defects, rework), and consistency (reduced spread/variation in cycle time and fewer “stuck with one person” delays). Establish a baseline, keep other changes minimal when possible, and then inspect the time-series results after the knowledge-sharing practices start.
Practical approach:
The key is measuring delivery outcomes, not just participation in knowledge-sharing activities.
Outcome-focused trends and variation (speed, quality, consistency) show whether knowledge sharing is producing measurable improvement.
Topic: Leadership
An agile team onboards to an internal data platform and begins seeing recurring production incidents after deployments. You learn another team had the same incident pattern last year and documented the causes and fixes in the organization’s postmortem/lessons-learned knowledge base.
As the team’s agile lead, what is the best next step?
Best answer: D
What this tests: Leadership
Explanation: The best next step is to leverage existing organizational knowledge assets before reinventing analysis or solutions. Reviewing prior postmortems with the team quickly surfaces known root causes, effective mitigations, and context-specific constraints. This supports faster inspection and adaptation while preserving team ownership of the changes.
When a problem has likely occurred before, an agile leader should enable rapid learning by pulling in organizational knowledge assets (e.g., incident postmortems, lessons learned, internal wikis, communities of practice) and making them actionable for the team. In this scenario, the team can shorten the feedback loop by starting from proven findings rather than repeating discovery work under production pressure.
A practical sequence is:
This approach avoids premature escalation while still enabling the team to adapt their delivery practices quickly.
Using documented organizational lessons learned is the fastest way to avoid repeating known mistakes and select proven countermeasures.
Topic: Leadership
A product team has missed its iteration goal for three iterations. Their board shows the “In Review/QA” column growing each week, and many completed stories are reopened after product review. Developers say work is “done” when code is merged and unit tests pass; the product owner says stories are “not what I expected.” Defect escapes are low, and priorities have been stable. Retrospectives often turn into arguments about what “done” means.
What is the most likely underlying cause?
Best answer: A
What this tests: Leadership
Explanation: The key clue is repeated reopenings and conflict over what qualifies as “done,” despite stable priorities and low defect escapes. That pattern points to unclear, unshared quality and acceptance expectations (Definition of Done and acceptance criteria), which creates rework loops and a growing review/QA queue. Making expectations explicit enables a concrete action plan to prevent recurrence.
This is a classic “rework loop” problem caused by unclear or inconsistent completion criteria. When the team’s Definition of Done is effectively “code merged,” but the product owner evaluates “done” based on unspoken expectations, work repeatedly bounces back from review, inflating WIP in downstream columns and triggering conflict.
In a facilitated problem-solving session, guide the team to surface and align on explicit policies such as:
With expectations made explicit, the team can create an action plan that reduces reopenings and stabilizes flow.
Misaligned, implicit completion and acceptance expectations drive rework, queues, and conflict even when priorities and defect rates are stable.
Use the PMI-ACP Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PMI-ACP guide on PMExams.com, then return to PM Mastery for timed practice.