PMI-ACP — PMI Agile Certified Practitioner Cheat Sheet

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

Item	Reference
Vendor/provider	PMI
Official title	PMI Agile Certified Practitioner (PMI-ACP)
Official code	PMI-ACP
Page purpose	Independent Cheat Sheet for real-exam preparation and original practice support
Best study posture	Think like an agile practitioner: servant leadership, value delivery, empirical adaptation, collaboration, transparency, and continuous improvement

PMI-ACP questions are usually scenario-based. The best answer is often the one that preserves agile values while solving the immediate problem with the least unnecessary process.

Agile Mindset: High-Yield Exam Rules

Notes and examples

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.

Agile Values and Principles in Exam Language

Agile Roles and Accountability

Notes and examples

Role Decision Traps

Question asks who should…	Best answer
Prioritize backlog items	Product owner/customer representative
Estimate technical effort	Team doing the work
Decide how work is implemented	Team
Remove organizational impediments	Servant leader/agile practitioner facilitates removal, often with management support
Accept completed stories	Product owner/customer representative using acceptance criteria
Change sprint/iteration goal mid-iteration	Product owner and team collaborate; avoid disruption unless value/risk justifies it
Define Definition of Done	Team, with organizational/product quality standards considered
Facilitate retrospective	Scrum Master/agile coach/servant leader
Resolve conflict inside the team	Team first, facilitated by servant leader if needed

Framework Selection Matrix

Scrum-Oriented Reference

Kanban and Flow Reference

Notes and examples

Kanban Scenario Responses

Symptom	Likely issue	Best response
Many items started, few finished	Excess WIP	Enforce WIP limits; swarm to finish
One column grows rapidly	Bottleneck	Investigate constraint; rebalance skills/capacity
Urgent work disrupts flow	Poor intake/class-of-service policy	Make expedite policy explicit
Cycle time is unpredictable	Inconsistent work size or hidden blockers	Split work, visualize blockers, improve policies
Team members idle because WIP limit reached	Flow discipline is working	Help finish existing work rather than start new work

XP and Technical Quality Practices

Value-Driven Delivery

Notes and examples

Prioritization Methods

Method	Use when…	How it works	Trap
MoSCoW	Need simple stakeholder priority categories	Must, Should, Could, Won’t for now	Too many “Must” items
Kano	Need customer satisfaction insight	Basic, performance, excitement features	Building delight features while basics fail
WSJF	Need economic sequencing	WSJF = Cost of Delay / Job Size	Ignoring risk reduction or time criticality
Relative weighting	Need compare value/risk/cost	Score options against weighted criteria	False precision from weak data
Value vs. risk matrix	Need sequence learning	High value/high risk often early to reduce uncertainty	Saving major risks until late
Buy-a-feature	Need stakeholder tradeoff discussion	Stakeholders allocate limited budget to features	Dominant stakeholder bias
Story mapping	Need release slicing	Map user journey, then slice releases	Treating map as fixed scope

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

Notes and examples

Estimation Reference

Technique	Best use	Key point
Story points	Relative size/complexity/uncertainty	Not hours; team-specific
Planning poker	Collaborative relative estimation	Discuss outliers to uncover assumptions
Affinity estimating	Quickly group many items by relative size	Useful for early backlog sizing
T-shirt sizing	Rough sizing	Good for early uncertainty
Ideal days	Effort estimate excluding interruptions	Less preferred than relative points in many agile scenarios
Wideband Delphi	Expert consensus estimate	Useful when multiple experts estimate independently then discuss
Three-point estimate	Estimate uncertainty with optimistic/most likely/pessimistic	Useful for risk-aware forecasting
Velocity	Completed points per iteration	Use historical average/range, not target imposed by management

Forecasting Formulas

Use ranges when possible. A single deterministic forecast is weaker than a transparent forecast with uncertainty.

\[ \text{Iterations Needed} = \frac{\text{Remaining Backlog Size}}{\text{Average Velocity}} \]\[ \text{Release Forecast} = \text{Current Date} + (\text{Iterations Needed} \times \text{Iteration Length}) \]\[ \text{Velocity} = \frac{\text{Completed Story Points}}{\text{Iteration}} \]

High-yield caution: velocity is a planning measure, not a productivity quota for comparing teams.

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:

1. Clarify the story through conversation and examples.
2. Let the team doing the work estimate it.
3. Use relative sizing where appropriate.
4. Re-estimate when meaningful new information appears.
5. 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.

Metrics and Information Radiators

Agile EVM and Core Formulas

PMI-ACP scenarios may include earned value terms. Use them only when the question gives PV, EV, AC, BAC, or similar data. Otherwise, agile-native measures such as burn charts, velocity, flow, and working product are usually more relevant.

\[ \text{CPI} = \frac{\text{EV}}{\text{AC}} \]\[ \text{SPI} = \frac{\text{EV}}{\text{PV}} \]

Risk, Uncertainty, and Problem Detection

Notes and examples

Risk Formulas

\[ \text{Risk Exposure} = \text{Probability} \times \text{Impact} \]\[ \text{Expected Monetary Value} = \text{Probability} \times \text{Monetary Impact} \]

Response type	When appropriate	Example
Avoid	Eliminate threat	Choose simpler architecture to remove risk
Mitigate	Reduce probability or impact	Build prototype; add automated tests
Transfer	Shift impact/ownership	Contract/vendor insurance approach where suitable
Accept	Monitor without active response	Low exposure risk within tolerance
Exploit	Ensure opportunity occurs	Assign best team to high-value opportunity
Enhance	Increase probability/impact of opportunity	Add experiment to improve chance of benefit
Share	Partner to capture opportunity	Joint venture or specialist collaboration

Stakeholder Engagement and Communication

Notes and examples

Communication Richness

Communication type	Richness	Best use
Face-to-face / live video	High	Ambiguity, conflict, collaboration, complex design
Workshop	High	Alignment, backlog discovery, planning
Chat / team channel	Medium	Fast coordination, simple questions
Visual board / dashboard	Medium	Shared state and transparency
Email / document	Lower	Formal record, broad distribution, non-urgent detail

Exam trap: agile favors direct, frequent, high-bandwidth communication, but it does not eliminate documentation. Documentation should be useful, sufficient, and value-adding.

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.

User Stories and Acceptance Criteria

Story Examples

Definition of Done vs. Acceptance Criteria

High-yield distinction: a story can meet its acceptance criteria but still not be “done” if it fails the team’s Definition of Done.

Agile Quality Reference

Servant Leadership and Team Performance

Team Development

Notes and examples

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.

Conflict and Collaboration

Change Control: Agile vs. Predictive Distinctions

“What Should the Agile Practitioner Do Next?” Decision Table

Artifact Selection Cheat Sheet

Agile Planning Workflow

    flowchart TD
	    A[Product vision and goals] --> B[Identify users, needs, and outcomes]
	    B --> C[Create and order product backlog]
	    C --> D[Refine stories and acceptance criteria]
	    D --> E[Estimate relatively]
	    E --> F[Plan release forecast using velocity/range]
	    F --> G[Plan iteration goal and selected work]
	    G --> H[Deliver done increment]
	    H --> I[Review with stakeholders]
	    H --> J[Retrospect process]
	    I --> C
	    J --> D

Common PMI-ACP Scenario Traps

Agile vs. Waterfall Answer Clues

Lean Waste Reference

Cheat Sheet Checklist Before Practice Questions

• Can you identify who owns priority, estimation, acceptance, and process facilitation?
• Can you distinguish acceptance criteria, Definition of Done, and Definition of Ready?
• Can you choose between Scrum, Kanban, Lean, and XP based on scenario clues?
• Can you interpret velocity, burn-down, burn-up, CFD, cycle time, and lead time?
• Can you apply WIP limits when work is started but not finished?
• Can you choose collaborative responses before escalation?
• Can you prioritize using value, risk, dependencies, cost of delay, and learning?
• Can you spot metric misuse, especially individual velocity or imposed velocity targets?
• Can you explain why quality is built in rather than inspected at the end?
• Can you respond to change without abandoning transparency, focus, or product ownership?

PMI-ACP Cheat Sheet purpose

This Cheat Sheet 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.

Quick decision rules for PMI-ACP scenarios

Framework essentials

Scrum review

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

Notes and examples

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.

Problem detection and resolution

Impediments, risks, and issues

Notes and examples

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.

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

Metrics quick table

Notes and examples

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

1. Choosing command-and-control answers. If the answer assigns tasks, dictates estimates, or bypasses team ownership, be skeptical.

2. Assuming agile means no discipline. Agile still uses planning, risk management, quality standards, documentation, and governance where valuable.

3. Treating the backlog as fixed scope. The backlog evolves as the team and stakeholders learn.

4. Confusing product owner and Scrum Master responsibilities. The product owner maximizes product value. The Scrum Master facilitates process improvement and removes impediments.

5. Counting partially completed work. Agile progress is based on completed, accepted, Done work.

6. Using velocity as a target. Velocity is mainly for forecasting, not a performance quota.

7. Ignoring technical debt. Shortcuts may appear faster but often reduce future delivery speed and quality.

8. Skipping retrospectives under pressure. Pressure is a reason to improve the system, not a reason to stop improvement.

9. Accepting every change immediately. Agile welcomes change through transparent backlog prioritization, not uncontrolled disruption.

10. 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 Cheat Sheet to guide focused practice:

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.

Put the review into practice