PMI-ACP — PMI Agile Certified Practitioner Quick Review

Last revised: June 29, 2026

Quick Review for PMI-ACP candidates covering agile mindset, delivery, teams, planning, metrics, and common exam traps.

PMI-ACP Quick Review purpose

This Quick Review is for candidates preparing for PMI’s PMI Agile Certified Practitioner (PMI-ACP) exam, code PMI-ACP. Use it as a fast conceptual refresh before moving into topic drills, mock exams, and detailed explanations in an PM Mastery question bank.

The exam is not just a terminology test. Scenario questions often ask what an agile practitioner should do next, first, or best. The strongest answer usually supports agile values: deliver value early, collaborate with stakeholders, make work visible, empower the team, inspect real results, and adapt based on feedback.

Exam mindset: choose the answer that improves transparency, collaboration, customer value, team ownership, quality, and learning—without reverting to command-and-control project management.

High-yield agile mindset

The Agile Manifesto, exam-style

Agile value	What it means in exam scenarios	Common trap
Individuals and interactions over processes and tools	Use conversation, collaboration, facilitation, and shared understanding.	Thinking agile means no process or no tools.
Working product over comprehensive documentation	Deliver tested increments that stakeholders can inspect.	Choosing excessive documentation instead of usable value.
Customer collaboration over contract negotiation	Keep the product owner, customers, and stakeholders engaged.	Hiding behind scope documents when feedback changes priorities.
Responding to change over following a plan	Re-plan based on learning while protecting team focus.	Treating every change as immediate work or freezing all change.

“Over” does not mean “instead of.” Agile teams still plan, document, estimate, manage risk, and use process. They do so just enough to support value delivery and learning.

Core agile principles to recognize quickly

Principle	Exam signal	Better response
Deliver early and often	Stakeholders need confidence or feedback.	Produce a small, usable increment or prototype.
Welcome change	New market or customer information appears.	Reprioritize the backlog with the product owner.
Collaborate daily	Misunderstanding, handoff delay, or silo behavior.	Improve direct communication and shared ownership.
Build around motivated people	Team is waiting for task assignments.	Coach self-organization and clarify goals.
Working product is the primary progress measure	Reports look good, but value is unclear.	Demonstrate completed, accepted work.
Sustainable pace	Team is relying on overtime.	Address capacity, scope, quality, and impediments.
Technical excellence	Defects, rework, or fragile code increase.	Strengthen Definition of Done and engineering practices.
Reflect and adjust	Repeated problems occur.	Use retrospectives, root cause analysis, and improvement experiments.

Quick decision rules for PMI-ACP scenarios

If the scenario says…	Prefer an answer that…	Avoid answers that…
Stakeholders are unhappy after a review	Captures feedback, clarifies value, and reprioritizes the backlog.	Blames the team or refuses change because the plan was approved.
A customer requests a change during an iteration	Routes it through the product owner/backlog and assesses impact.	Automatically inserts it into the current iteration.
Velocity has dropped	Investigates impediments, quality issues, team capacity, or estimation changes.	Pressures the team to “increase velocity” or compares teams.
Defects are escaping	Improves built-in quality, testing, Definition of Done, and root cause learning.	Adds a final inspection phase as the main solution.
Work is stuck in progress	Swarms on blockers, enforces WIP limits, and finishes before starting more.	Starts additional work to keep everyone busy.
The team is dependent on a specialist	Encourages pairing, knowledge sharing, T-shaped skills, and cross-training.	Assigns all related work permanently to the specialist.
A conflict occurs	Facilitates transparent discussion and collaborative problem solving.	Suppresses the conflict or escalates immediately without team engagement.
Requirements are unclear	Uses refinement, examples, acceptance criteria, prototypes, or spikes.	Demands complete upfront specification before any learning.
The team misses commitments repeatedly	Reviews capacity, estimation, slicing, impediments, and retrospective actions.	Punishes the team or unilaterally assigns tasks.
Executives want status	Uses information radiators, demos, burn charts, flow metrics, and value progress.	Creates heavy manual reports that do not improve transparency.

Framework essentials

Scrum review

Scrum is common on PMI-ACP questions because it gives clear roles, events, and artifacts.

Scrum element	Exam-relevant meaning	Common mistake
Product Owner	Owns product value, ordering of the product backlog, and acceptance direction.	Treating the product owner as a traditional project sponsor only.
Scrum Master	Servant leader who facilitates Scrum, removes impediments, and coaches the team and organization.	Treating the Scrum Master as the team’s task manager.
Developers / team	Cross-functional people who create the increment and manage their work.	Assuming the project manager assigns daily tasks.
Product Backlog	Ordered list of product work, refined as learning occurs.	Treating it as fixed scope.
Sprint Backlog	Team’s plan for the sprint, including selected work and delivery approach.	Allowing outsiders to change it at will.
Increment	Potentially releasable, integrated, usable result that meets the Definition of Done.	Counting partially complete work as done.
Sprint Planning	Aligns on goal, selected backlog items, and delivery plan.	Planning beyond capacity or skipping acceptance clarity.
Daily Scrum	Team inspects progress and adapts the plan.	Turning it into a status report to the Scrum Master.
Sprint Review	Stakeholders inspect the increment and discuss feedback.	Treating it as a sign-off meeting only.
Retrospective	Team inspects process and chooses improvements.	Skipping it when the team is busy.
Backlog Refinement	Clarifies, splits, estimates, and reorders upcoming work.	Waiting until planning to discover unclear work.

Kanban and flow review

Kanban questions usually focus on visibility, work-in-progress, bottlenecks, and flow improvement.

Kanban concept	What to know
Visualize work	Make work states visible so bottlenecks, blockers, and queues can be managed.
Limit WIP	Reduce multitasking, expose constraints, and improve flow.
Pull system	Work is pulled when capacity exists, not pushed onto overloaded people.
Explicit policies	Define how work enters, moves, blocks, and exits the system.
Manage flow	Use data such as cycle time, throughput, aging work, and cumulative flow.
Improve collaboratively	Use small experiments and shared ownership of the workflow.

Key distinction:

Metric	Meaning
Lead time	Time from request to delivery.
Cycle time	Time from active work start to completion.
Throughput	Number of items completed in a period.
WIP	Items started but not finished.
Work item age	How long an active item has been in progress.

Little’s Law is useful conceptually for flow questions:

\[ \text{Average WIP} = \text{Average Throughput} \times \text{Average Cycle Time} \]

If WIP rises while throughput stays constant, cycle time usually grows. The agile answer is often to reduce WIP, remove blockers, or improve the constraint—not to start more work.

Extreme Programming and technical practices

XP-style practices appear in quality, feedback, and engineering-discipline scenarios.

Practice	Purpose	Exam trap
Test-driven development	Write tests before code to clarify behavior and support design.	Treating testing as a late phase.
Acceptance test-driven development	Align business expectations with executable examples.	Assuming user stories alone are enough.
Continuous integration	Integrate frequently to detect problems early.	Delaying integration until the end.
Refactoring	Improve internal design without changing external behavior.	Calling all refactoring “gold plating.”
Pair programming	Improve quality, learning, and shared ownership.	Assuming it always wastes capacity.
Collective code ownership	The team owns the codebase, not isolated individuals.	Creating single points of failure.
Simple design	Build what is needed now while preserving adaptability.	Overengineering for speculative future needs.
Sustainable pace	Maintain long-term delivery capability.	Normalizing overtime as the solution.

Lean principles

Lean thinking supports many PMI-ACP answers.

Lean idea	Practical exam interpretation
Eliminate waste	Remove delays, handoffs, rework, unused features, excess WIP, and task switching.
Amplify learning	Use short feedback loops, experiments, prototypes, and reviews.
Decide as late as responsible	Keep options open until enough information is available, but do not avoid decisions.
Deliver fast	Shorten cycle time and deliver small batches.
Empower the team	Let the people closest to the work improve the work.
Build integrity in	Quality is designed into the process, not inspected in at the end.
Optimize the whole	Avoid local optimization that harms end-to-end value flow.

Value-driven delivery

Product vision, roadmap, releases, and iterations

Agile planning happens at multiple levels.

Planning level	Purpose	Detail level
Vision	Why the product exists and what value it should create.	Strategic and stable.
Roadmap	Major outcomes, themes, or capabilities over time.	Directional and adaptable.
Release plan	Forecast of valuable increments or market deliveries.	Medium detail, updated with learning.
Iteration plan	Near-term work the team expects to complete.	Detailed enough for execution.
Daily plan	Team coordination and adaptation.	Very detailed and short-lived.

Exam trap: agile planning is not “no planning.” It is progressive elaboration and rolling-wave planning. Plan more detail for near-term work and keep longer-term plans adaptable.

Backlog and prioritization

The product backlog is ordered to maximize value, reduce risk, and support learning.

Prioritization factor	Typical meaning
Business value	Revenue, cost savings, mission value, customer satisfaction, or strategic alignment.
Risk reduction	Work that reduces uncertainty or exposes feasibility issues.
Dependencies	Work needed before other valuable work can be completed.
Cost of delay	Economic impact of waiting.
Learning value	Knowledge gained through prototypes, spikes, or experiments.
Effort / size	Smaller valuable items may be delivered sooner.
Compliance or obligation	Required work may affect ordering, but avoid inventing rules not given in the question.

Common prioritization methods:

Method	Use
MoSCoW	Must, Should, Could, Won’t for scope negotiation.
Kano	Basic needs, performance needs, delighters, indifferent features.
Relative weighting	Compare value, risk, and effort.
Cost of delay	Prioritize work where delay is expensive.
WSJF-style thinking	Compare cost of delay to job size.
Story mapping	Organize user activities and slice releases around workflows.

A common value formula is:

\[ \text{WSJF} = \frac{\text{Cost of Delay}}{\text{Job Size}} \]

Use this as a prioritization concept: high delay cost and small size often move work earlier. Do not treat any formula as a replacement for product owner judgment and stakeholder collaboration.

User stories and acceptance criteria

A user story expresses a need from a user or stakeholder perspective. A common structure is:

“As a [user], I want [capability], so that [benefit].”

High-quality stories are often described by INVEST:

INVEST element	Meaning
Independent	Can be planned and delivered with minimal dependency.
Negotiable	Encourages conversation, not a rigid contract.
Valuable	Delivers user, customer, or business value.
Estimable	Team can size it well enough for planning.
Small	Fits within the team’s delivery cadence.
Testable	Has clear acceptance conditions.

Acceptance criteria define when a specific story satisfies stakeholder expectations. The Definition of Done defines the team’s quality bar for completed work across items.

Concept	Applies to	Example
Acceptance criteria	A specific story or feature	“Given a valid email, when the user submits the form, then a confirmation is sent.”
Definition of Done	Work generally	Code reviewed, tested, integrated, documented as needed, accepted, and deployable.
Definition of Ready	Optional readiness guide for upcoming work	Story has clear value, acceptance criteria, dependencies identified, and estimate.

Common trap: a story can meet acceptance criteria but still not be “done” if it fails the team’s Definition of Done.

Adaptive planning and estimation

Estimation concepts

Concept	Exam focus
Relative estimation	Compare items to each other rather than estimating exact hours.
Story points	Express relative size, complexity, uncertainty, and effort.
Planning poker	Team-based estimation that reveals assumptions and differences.
Affinity estimating	Fast grouping of many items by relative size.
T-shirt sizing	Coarse sizing such as S, M, L, XL.
Ideal days	Estimate assuming no interruptions; less common than relative sizing in agile scenarios.
Spikes	Timeboxed research to reduce uncertainty.

Strong agile estimation behavior:

Clarify the story through conversation and examples.
Let the team doing the work estimate it.
Use relative sizing where appropriate.
Re-estimate when meaningful new information appears.
Avoid pretending estimates are guarantees.

Velocity and forecasting

Velocity is the amount of work a team completes in an iteration, commonly measured in story points.

\[ \text{Average Velocity} = \frac{\text{Completed Story Points Across Selected Iterations}}{\text{Number of Iterations}} \]

Only completed, accepted work counts. Partially complete work should not be credited as velocity.

Metric	Good use	Bad use
Velocity	Forecasting for the same team under similar conditions.	Comparing teams or setting performance targets.
Burn-down chart	Shows remaining work over time.	Treating a perfect line as proof of value.
Burn-up chart	Shows completed work and total scope, useful when scope changes.	Ignoring stakeholder feedback and value delivered.
Release forecast	Communicates likely outcomes and uncertainty.	Presenting a forecast as a fixed commitment.

If velocity is unstable, look for changing team membership, unclear stories, technical debt, excessive WIP, interruptions, dependencies, or inconsistent Definition of Done.

Scope, schedule, and cost tradeoffs

Agile teams often keep timeboxes stable and vary scope based on value.

Situation	Agile-friendly response
Fixed date with too much scope	Prioritize highest-value work and negotiate lower-value scope.
New requirement appears	Add to backlog, compare value, and reorder transparently.
Team cannot complete planned work	Inspect causes, protect quality, and adapt future planning.
Stakeholder demands certainty too early	Provide ranges, assumptions, risks, and frequent inspection points.

Exam trap: do not “solve” schedule pressure by cutting quality practices, skipping testing, or forcing overtime as the default.

Stakeholder engagement

Stakeholder collaboration

Agile stakeholder engagement is frequent, transparent, and value-centered.

Technique	Use
Product vision	Align stakeholders around purpose and outcomes.
Personas	Understand users and their needs.
Journey maps	Identify user experience and pain points.
Story maps	Connect user activities to release slices.
Reviews / demos	Inspect working product and collect feedback.
Information radiators	Make progress, risks, and blockers visible.
Backlog refinement	Clarify upcoming work with product and technical input.
Workshops	Build shared understanding and resolve ambiguity.

When stakeholders disagree, the best PMI-ACP-style answer usually involves facilitation, shared criteria, product owner prioritization, and transparency—not private escalation as the first response.

Communication patterns

Environment	Better approach
Co-located team	Use face-to-face conversation, visible boards, and osmotic communication.
Distributed team	Use collaboration tools, working agreements, overlap hours, clear boards, and deliberate facilitation.
Many stakeholders	Use reviews, demos, stakeholder maps, and product owner alignment.
High uncertainty	Increase feedback frequency and use prototypes or experiments.

The best communication method depends on complexity and urgency. For ambiguous or sensitive topics, richer communication is usually better than email-only updates.

Team performance and leadership

Servant leadership

An agile practitioner supports the team by removing impediments, coaching, facilitating, and protecting the environment for delivery.

Servant-leader behavior	Not servant leadership
Facilitating decisions	Making every decision for the team.
Removing organizational impediments	Ignoring blockers because “the team owns it.”
Coaching agile values	Policing ceremonies without explaining value.
Protecting focus	Isolating the team from all stakeholder feedback.
Encouraging self-organization	Abandoning the team without support.
Promoting continuous improvement	Blaming individuals for systemic issues.

Team development and conflict

Agile teams need psychological safety, clear goals, and healthy conflict.

Situation	Strong response
New team is confused	Clarify vision, roles, working agreements, and team norms.
Conflict over estimates	Facilitate discussion of assumptions and complexity.
Dominant stakeholder pressures team	Use product owner prioritization and transparent tradeoffs.
Team avoids raising problems	Build safety, make impediments visible, and respond constructively.
Specialist bottleneck	Pair, cross-train, swarm, and reduce dependency.
Low morale	Investigate root causes, support autonomy, and address impediments.

Tuckman’s model may appear conceptually:

Stage	Team signal	Agile support
Forming	Polite, uncertain, role-seeking.	Provide clarity and working agreements.
Storming	Conflict and competing approaches.	Facilitate healthy conflict and shared norms.
Norming	Team practices stabilize.	Reinforce collaboration and ownership.
Performing	Team adapts and delivers effectively.	Remove impediments and support improvement.

Problem detection and resolution

Impediments, risks, and issues

Term	Meaning	Agile response
Risk	Uncertain event that may affect outcomes.	Make visible, prioritize, mitigate, experiment, or monitor.
Issue	Current problem already affecting work.	Resolve, swarm, escalate when outside team control.
Impediment	Anything blocking or slowing the team.	Scrum Master/agile lead helps remove or reduce it.
Dependency	Work reliant on another team, person, or system.	Visualize, coordinate, split work, or reduce dependency.
Technical debt	Future cost caused by shortcuts or weak design.	Make visible, prioritize repayment, strengthen quality practices.

Root cause tools

Tool	Best use
Five Whys	Explore underlying causes beyond symptoms.
Fishbone diagram	Categorize possible causes of complex problems.
Pareto analysis	Focus on the few causes creating most effects.
Retrospective	Inspect team process and select improvements.
Control chart	Understand process variation and cycle-time stability.
Cumulative flow diagram	Detect WIP buildup, bottlenecks, and flow imbalance.

Exam trap: if the same problem repeats, do not choose a one-time heroic fix. Choose root cause analysis, process improvement, and team learning.

Defects and quality

Agile quality is built in continuously.

Quality problem	Strong response
Many late defects	Improve testing, integration, Definition of Done, and root cause analysis.
Unclear expectations	Add acceptance criteria, examples, and stakeholder conversation.
Integration failures	Integrate more frequently and automate checks.
Fragile code	Refactor, improve design, and manage technical debt.
Rushed testing	Protect quality; negotiate scope rather than lowering Done.
Repeated escaped defects	Add feedback loops and improve prevention, not just detection.

Continuous improvement

Continuous improvement is not a one-time lesson-learned meeting at project close. It is built into agile delivery.

Practice	What to remember
Retrospectives	Inspect how the team works and choose actionable improvements.
Kaizen	Small, ongoing improvements.
PDCA / PDSA	Plan, do, check/study, act on experiments.
Working agreements	Team-owned norms that can evolve.
Metrics review	Use data to learn, not punish.
Improvement backlog	Track improvement actions like real work.

A good retrospective action is specific, owned, visible, and small enough to try soon.

Metrics quick table

Metric or artifact	Tells you	Watch out for
Velocity	Forecasting capacity for the same team.	Misuse as productivity ranking.
Burn-down	Remaining work in a timebox or release.	Can hide scope changes.
Burn-up	Completed work and total scope trend.	Still needs value interpretation.
Cumulative flow diagram	Flow stability, bottlenecks, WIP buildup.	Requires understanding workflow states.
Cycle time	How long active work takes.	Not the same as lead time.
Lead time	Customer wait from request to delivery.	Can include queue time before work starts.
Throughput	Completed items per time period.	Item size variation can distort interpretation.
WIP	Started but unfinished work.	Too much WIP increases delay and context switching.
Escaped defects	Quality issues found after release or acceptance.	Should trigger prevention improvements.
Team happiness / morale	Sustainability and team health signals.	Should not replace delivery and quality metrics.
Business value delivered	Outcome-oriented progress.	Harder to measure but more important than output alone.

Use metrics for transparency and improvement. The wrong exam answer often uses metrics to punish individuals or force unrealistic commitments.

Common PMI-ACP candidate mistakes

Choosing command-and-control answers. If the answer assigns tasks, dictates estimates, or bypasses team ownership, be skeptical.
Assuming agile means no discipline. Agile still uses planning, risk management, quality standards, documentation, and governance where valuable.
Treating the backlog as fixed scope. The backlog evolves as the team and stakeholders learn.
Confusing product owner and Scrum Master responsibilities. The product owner maximizes product value. The Scrum Master facilitates process improvement and removes impediments.
Counting partially completed work. Agile progress is based on completed, accepted, Done work.
Using velocity as a target. Velocity is mainly for forecasting, not a performance quota.
Ignoring technical debt. Shortcuts may appear faster but often reduce future delivery speed and quality.
Skipping retrospectives under pressure. Pressure is a reason to improve the system, not a reason to stop improvement.
Accepting every change immediately. Agile welcomes change through transparent backlog prioritization, not uncontrolled disruption.
Defaulting to escalation. Escalation is appropriate when needed, especially for impediments outside team control, but first look for collaboration, facilitation, and transparency.

Fast scenario-answer checklist

Before selecting an answer, ask:

Does it deliver or protect customer value?
Does it increase transparency?
Does it involve the right people, especially the team and product owner?
Does it preserve self-organization?
Does it use real feedback from working product?
Does it protect quality and the Definition of Done?
Does it reduce WIP, blockers, risk, or uncertainty?
Does it support sustainable pace?
Does it improve the system rather than blame individuals?
Does it adapt the plan without creating chaos?

If two answers both sound reasonable, the better PMI-ACP answer is usually the one that is more collaborative, empirical, value-focused, and sustainable.

Last-minute topic drill plan

Use this Quick Review to guide focused practice:

Practice area	What to drill
Agile mindset	Manifesto values, servant leadership, inspect-and-adapt decisions.
Scrum	Roles, events, artifacts, Definition of Done, backlog ownership.
Kanban and flow	WIP limits, cycle time, throughput, bottlenecks, cumulative flow.
Value delivery	Prioritization, user stories, MVP/MMF, acceptance criteria.
Planning	Relative estimation, velocity, release forecasts, rolling-wave planning.
Stakeholders	Reviews, feedback, communication, conflict, product owner decisions.
Teams	Self-organization, coaching, motivation, conflict, distributed collaboration.
Problems and improvement	Root cause analysis, retrospectives, technical debt, quality practices.
Metrics	Proper metric use and common misuse.

For PM Mastery practice, work through original practice questions by topic first, then move into mixed question-bank sets. Use the detailed explanations to understand why the best answer is agile—not merely why the other choices are wrong.

Practical next step

Next, choose one weak area from this review and complete a focused PMI-ACP topic drill. After reviewing the detailed explanations, take a mixed question-bank set to practice switching between agile mindset, delivery, planning, stakeholder, team, metrics, and problem-resolution scenarios.

Continue in PM Mastery

Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official PMI questions, copied live-exam content, or exam dumps.

Study Plan