PMI-ACP — PMI Agile Certified Practitioner Exam Blueprint
A practical PMI-ACP exam blueprint for PMI Agile Certified Practitioner candidates reviewing agile mindset, value delivery, stakeholders, teams, planning, risk, quality, and metrics.
How to Use This Exam Blueprint
Use this independent Exam Blueprint to prepare for the PMI Agile Certified Practitioner (PMI-ACP), exam code PMI-ACP, from PMI. It translates agile exam-prep areas into practical readiness checks.
For each row:
- Mark Green if you can explain it, apply it in a scenario, and choose the best next action.
- Mark Yellow if you recognize the terms but miss judgment questions.
- Mark Red if you need to relearn the concept or confuse it with predictive project management habits.
This is a study-readiness map, not a claim of exact official exam weights, scoring rules, or PMI exam structure.
Public Blueprint View: PMI-ACP Readiness Areas
| Readiness area | What to review | You are ready when you can… | Common weak spots |
|---|---|---|---|
| Agile mindset and principles | Empiricism, transparency, inspection, adaptation, servant leadership, customer collaboration, responding to change | Choose an agile response that maximizes learning, value, and collaboration instead of forcing a fixed plan | Treating agile as “no planning”; over-controlling the team |
| Value-driven delivery | Product vision, value, MVP/MMF, prioritization, backlog ordering, release goals, customer feedback | Explain why one backlog item should be delivered before another based on value, risk, learning, and dependency | Prioritizing by stakeholder volume, seniority, or effort alone |
| Stakeholder engagement | Stakeholder identification, engagement levels, feedback loops, demos, reviews, personas, communication | Select the right engagement action when stakeholders disagree, are unavailable, or change priorities | Escalating too quickly; waiting until the end for feedback |
| Team performance | Self-organization, team charter, working agreements, psychological safety, conflict, coaching, facilitation | Support team ownership while removing impediments and improving collaboration | Project manager “assigns” all tasks; ignoring team conflict |
| Adaptive planning | Rolling-wave planning, release planning, iteration planning, estimation, velocity, capacity, progressive elaboration | Reforecast without pretending estimates are guarantees | Treating story points as hours; promising scope/date/cost certainty |
| Problem detection and resolution | Impediments, blockers, root cause analysis, risk responses, spikes, issue escalation | Decide what to fix now, what to escalate, and what to make visible | Hiding bad news; solving symptoms rather than causes |
| Continuous improvement | Retrospectives, kaizen, experiments, lessons learned, process adaptation | Turn retrospective findings into small, trackable improvements | Holding retrospectives without action items |
| Quality and technical practices | Definition of Done, acceptance criteria, TDD, ATDD/BDD, CI, refactoring, pairing, defect prevention | Explain how agile builds quality in throughout delivery | Deferring testing; accepting incomplete work to “keep velocity” |
| Agile metrics and information radiators | Burndown, burnup, velocity, cycle time, lead time, WIP, cumulative flow, escaped defects | Interpret what a metric suggests and what action to take next | Using metrics to punish the team; comparing velocity across teams |
| Agile frameworks and methods | Scrum, Kanban, XP, Lean, hybrid delivery, tailoring | Match practices to the situation without relying on ceremony memorization | Confusing roles, events, artifacts, and flow-based practices |
| Governance, compliance, and constraints | Lightweight documentation, audit needs, procurement, contracts, risk, governance gates, hybrid reporting | Balance agility with organizational or regulatory constraints | Assuming agile means no documentation or no governance |
Core “Can You Do This?” Checklist
Agile mindset and servant leadership
- Explain why agile favors frequent feedback over detailed upfront certainty.
- Distinguish servant leadership from command-and-control management.
- Choose collaboration, facilitation, coaching, and transparency before escalation when appropriate.
- Identify when a team needs coaching, training, conflict resolution, or impediment removal.
- Explain why self-organizing teams still need goals, boundaries, and visible work.
- Recognize when a plan should be adapted because new information has changed risk, value, or feasibility.
- Avoid exam traps that make the agile practitioner the sole decision-maker for technical or product choices.
Value delivery and prioritization
- Define business value in practical terms: customer benefit, risk reduction, learning, revenue, compliance, cost avoidance, or strategic fit.
- Explain how a product vision, roadmap, release goal, and backlog connect.
- Prioritize backlog items using value, risk, dependency, cost of delay, learning, and stakeholder impact.
- Identify an MVP or minimum marketable feature without turning it into the full desired product.
- Explain why high-risk or high-learning items may be delivered early.
- Recognize when technical debt should be visible and prioritized.
- Choose the best next step when stakeholders request more scope than the team can deliver.
Stakeholder engagement
- Identify stakeholders who provide requirements, funding, acceptance, compliance input, operations support, or user feedback.
- Select an engagement approach for resistant, unavailable, over-involved, or conflicting stakeholders.
- Use product demos, reviews, prototypes, and feedback sessions to validate value.
- Distinguish stakeholder satisfaction from team velocity.
- Explain how personas, user journeys, and story mapping help clarify user value.
- Handle changing stakeholder expectations through backlog refinement and transparent trade-off discussions.
Team performance and collaboration
- Explain the purpose of a team charter or working agreement.
- Recognize signs of low trust, unclear roles, excessive multitasking, or poor communication.
- Facilitate conflict without immediately imposing a solution.
- Choose collaboration techniques for co-located, distributed, hybrid, or cross-functional teams.
- Explain how information radiators reduce status-report overhead.
- Identify when the agile practitioner should shield the team from disruption versus expose an impediment.
Planning, estimation, and forecasting
- Distinguish release planning, iteration planning, daily coordination, and backlog refinement.
- Explain relative estimation, story points, ideal time, affinity estimation, and planning poker at a practical level.
- Use velocity as a forecasting input, not a productivity weapon.
- Reforecast when team capacity, backlog size, priorities, or dependencies change.
- Explain the difference between lead time, cycle time, throughput, and WIP.
- Identify why fixed scope, fixed date, and fixed cost require explicit trade-off management.
Risk, impediments, and problem solving
- Identify risks from uncertainty, dependencies, skills gaps, stakeholder availability, technical complexity, and external constraints.
- Choose when to run a spike, prototype, experiment, or proof of concept.
- Distinguish an impediment from normal team work.
- Decide whether to resolve, escalate, accept, avoid, mitigate, or transfer a risk.
- Use root cause analysis rather than treating recurring symptoms.
- Update the right artifact: risk list, impediment log, backlog, release plan, or team agreement.
Quality and delivery discipline
- Explain the difference between acceptance criteria and Definition of Done.
- Identify why undone work, hidden defects, and incomplete testing distort progress.
- Recognize practices that prevent defects: TDD, ATDD, BDD, pairing, code review, CI, automation, refactoring.
- Explain why quality is a team responsibility, not only a tester responsibility.
- Decide what to do when a team wants to carry incomplete work forward.
- Explain how agile handles nonfunctional requirements and compliance requirements.
Artifact and Concept Checklist
| Artifact or concept | Know its purpose | Readiness prompt |
|---|---|---|
| Product vision | Provides direction and value intent | Can you explain how it guides backlog decisions? |
| Product roadmap | Shows high-level outcome or release direction | Can you adapt it when learning changes priorities? |
| Product backlog | Ordered list of product work | Can you explain refinement, ordering, and transparency? |
| User story | Describes user need and value | Can you improve a vague story without over-specifying design? |
| Acceptance criteria | Conditions for accepting a story | Can you identify missing, untestable, or ambiguous criteria? |
| Definition of Ready | Optional readiness guidance before work starts | Can you avoid using it as a bureaucratic gate? |
| Definition of Done | Shared quality completion standard | Can you explain why it protects transparency? |
| Iteration or sprint backlog | Selected work for a short delivery cycle | Can you explain who manages the work and how changes are handled? |
| Release plan | Forecast of deliverable increments | Can you update it based on velocity, scope, risk, or value changes? |
| Burndown chart | Shows remaining work trend | Can you spot scope growth, stalled progress, or unrealistic forecast? |
| Burnup chart | Shows completed work and total scope | Can you distinguish progress from scope change? |
| Cumulative flow diagram | Shows flow, WIP, and bottlenecks | Can you identify queues and overloaded workflow stages? |
| Kanban board | Visualizes workflow and work status | Can you explain WIP limits and pull-based flow? |
| Risk-adjusted backlog | Makes risk visible in ordering | Can you justify doing risky work earlier? |
| Impediment log | Tracks blockers needing attention | Can you decide what the team can resolve versus what needs escalation? |
| Retrospective action item | Specific improvement experiment | Can you make it measurable and follow up? |
| Team charter | Defines norms, values, and working agreements | Can you use it to address recurring collaboration issues? |
| Information radiator | Visible, shared project information | Can you choose one that improves transparency without micromanagement? |
Agile Roles and Responsibility Checks
| Role or participant | What to understand | Scenario cue |
|---|---|---|
| Product owner or product representative | Owns product direction, backlog ordering, and value decisions in many agile contexts | If priorities conflict, involve the product decision-maker instead of letting the team guess |
| Agile practitioner, Scrum Master, or team facilitator | Coaches agile practices, removes impediments, facilitates collaboration, protects process health | If the team is blocked by organizational issues, help remove or escalate the impediment |
| Development or delivery team | Cross-functional group that plans and performs the work | If technical decisions are needed, enable the team to decide within constraints |
| Sponsor or senior leader | Provides funding, strategic direction, or organizational support | If value, funding, or major constraint changes arise, make impacts visible |
| Customers and users | Validate outcomes and provide feedback | If feedback is missing, create feedback opportunities before assuming value |
| Functional managers or external groups | May control people, tools, environments, approvals, or dependencies | If dependency delays threaten delivery, expose and manage the dependency early |
Scenario and Decision-Point Checks
Use these prompts to test whether you can answer judgment questions, not just recall definitions.
| Scenario | Better agile response | Common exam trap |
|---|---|---|
| A senior stakeholder asks to add urgent scope during an iteration | Clarify value and urgency, involve the product owner/product decision-maker, assess impact, and protect the team from unmanaged disruption | Automatically accept the change or reject all change |
| The customer is unavailable for reviews | Escalate the impact of missing feedback, seek a delegate, schedule shorter feedback loops, and make assumptions visible | Continue building until final delivery |
| The team’s velocity drops for two iterations | Investigate causes with the team, review capacity and impediments, avoid blame, and reforecast transparently | Demand the team “increase velocity” |
| Work piles up in testing | Review WIP, bottlenecks, quality practices, and cross-functional collaboration | Add more work to development because developers are “free” |
| A defect is found near release | Assess severity, impact, Definition of Done, release risk, and customer value; make trade-offs visible | Hide the defect to preserve the release date |
| Stakeholders disagree on priority | Facilitate value-based prioritization using agreed criteria | Let the loudest or highest-ranking stakeholder decide without analysis |
| The team wants to skip the retrospective | Reinforce continuous improvement and keep the retrospective focused and useful | Cancel process improvement to save time |
| A requirement is unclear but high value | Refine with stakeholders, split the story, use examples or acceptance criteria, and consider a spike if uncertainty is technical | Start development and hope questions get answered later |
| A regulatory constraint exists | Incorporate compliance needs into backlog, Definition of Done, documentation, and review practices | Claim agile teams do not need documentation |
| A dependency threatens the release | Make the dependency visible, coordinate early, adjust plan or sequence, and escalate when outside team control | Wait until the dependency causes a missed commitment |
| A team member is repeatedly assigned urgent outside work | Expose capacity impact, discuss with responsible managers, and reforecast | Expect the team to maintain the same commitment |
| The product owner is making all technical decisions | Clarify decision boundaries and enable the technical team to own implementation choices | Accept role confusion because the product owner is accountable for value |
| Management asks for a fixed date and fixed scope | Explain uncertainty and trade-offs; provide forecasts and options | Promise certainty from early estimates |
| The team has too much work in progress | Reduce WIP, finish started work, inspect bottlenecks, and improve flow | Start more items so everyone stays busy |
| Retrospective actions never happen | Limit actions, make them visible, assign ownership, and inspect progress | Hold longer retrospectives without follow-through |
Agile Method and Framework Review
You do not need to treat every framework as identical. Be ready to compare the purpose of practices and select an approach that fits the situation.
| Area | Review points | Can you answer? |
|---|---|---|
| Scrum-style iterative delivery | Roles, events, backlog, iteration goal, review, retrospective, increment, Definition of Done | What should happen when new work appears mid-iteration? |
| Kanban-style flow | Visual workflow, WIP limits, pull system, lead time, cycle time, throughput, bottlenecks | What does it mean when work piles up in one column? |
| XP engineering practices | TDD, pair programming, continuous integration, refactoring, simple design, collective ownership | Which practice helps prevent defects instead of detecting them late? |
| Lean thinking | Value stream, waste reduction, flow, pull, small batches, continuous improvement | Which activity is waste if it does not improve value, learning, or risk reduction? |
| Hybrid delivery | Combining adaptive and predictive approaches where constraints require it | Which parts need upfront governance, and which parts can remain adaptive? |
| Scaling and multiple teams | Coordination, dependencies, integration, shared goals, synchronization, transparency | How do teams manage dependencies without centralizing every decision? |
Value, Prioritization, and Backlog Readiness
| Technique or factor | What it helps with | Watch for |
|---|---|---|
| Business value ranking | Orders work by expected benefit | Value must be explicit, not assumed |
| MoSCoW | Classifies Must, Should, Could, Won’t | “Must” cannot mean everything |
| Kano analysis | Differentiates basic, performance, and delight features | Delight features may not replace basic needs |
| Cost of delay | Highlights impact of waiting | Time-sensitive work may outrank larger but less urgent work |
| Risk-based prioritization | Addresses uncertainty early | Do not postpone all risky items until the end |
| Dependency ordering | Sequences work logically | Dependencies should be challenged, not blindly accepted |
| Story mapping | Connects user workflow to release slicing | Avoid slicing only by technical layer |
| MVP thinking | Tests value with minimum viable scope | MVP is not low-quality delivery |
| Technical debt visibility | Makes internal quality trade-offs explicit | Hidden debt reduces future adaptability |
Backlog item readiness prompts
- Is the user or customer benefit clear?
- Are acceptance criteria testable?
- Is the item small enough to complete within the intended planning horizon?
- Are dependencies visible?
- Is risk understood?
- Is the item ordered relative to value and urgency?
- Is there a shared understanding between business and delivery participants?
- Is quality included in the completion standard?
Planning and Estimation Checks
| Concept | Know this | Quick readiness check |
|---|---|---|
| Relative estimation | Estimates size compared with other work | Can you explain why story points are not hours? |
| Planning poker | Builds shared understanding through discussion | Can you identify when wide estimate gaps reveal uncertainty? |
| Affinity estimation | Groups items by relative size | Can you use it for larger backlog estimation? |
| Velocity | Amount of work completed over a period | Can you forecast without treating velocity as a target? |
| Capacity | Available team effort considering absences and other work | Can you adjust commitments when capacity changes? |
| Release forecast | Projection based on scope, velocity, risk, and priority | Can you present ranges or options instead of false certainty? |
| Rolling-wave planning | Plans near-term work in more detail | Can you explain why distant work remains less detailed? |
| Spike | Timeboxed research to reduce uncertainty | Can you choose a spike before committing to uncertain work? |
| Buffer or contingency | Handles uncertainty and risk | Can you avoid hiding unrealistic commitments inside estimates? |
Calculation-style checks to practice
Be prepared for simple interpretation and forecasting. Keep the logic clear.
| Check | Plain-language formula or interpretation |
|---|---|
| Remaining iterations | Remaining story points divided by average velocity |
| Capacity adjustment | Reduce planned work when availability decreases |
| Cycle time | Time from work start to work completion |
| Lead time | Time from request to delivery |
| Throughput | Items completed during a period |
| WIP concern | Too much started work often increases delays |
| Burndown trend | Remaining work should generally move downward; flat lines or upward jumps need explanation |
| Burnup trend | Completed work and total scope can show both progress and scope change |
| CFD bottleneck | Widening band often indicates work accumulating in that stage |
Metrics and Information Radiator Interpretation
| Metric or visual | What it can indicate | Poor use |
|---|---|---|
| Velocity | Forecasting based on completed work | Comparing unrelated teams or pressuring output |
| Burndown | Remaining work trend | Treating chart shape as more important than delivered value |
| Burnup | Progress plus total scope changes | Ignoring scope growth |
| Cumulative flow diagram | Flow, WIP, queues, bottlenecks | Looking only at total completed items |
| Lead time | Customer wait time | Ignoring delays before active work starts |
| Cycle time | Delivery process speed | Optimizing one step while hurting the whole system |
| Escaped defects | Quality issues found after release | Blaming testers instead of improving the system |
| Defect trend | Quality and stability signals | Hiding defects to protect metrics |
| Customer satisfaction | Perceived value and usability | Assuming satisfaction equals feature count |
| Team happiness or morale | Sustainability and collaboration health | Ignoring delivery outcomes |
| Business value delivered | Outcome-focused progress | Counting activity rather than value |
Quality, Definition of Done, and Technical Excellence
| Topic | Ready means you can… | Trap to avoid |
|---|---|---|
| Definition of Done | Explain a shared completion standard across work items | Calling work done when testing or integration is incomplete |
| Acceptance criteria | Connect expected behavior to testable conditions | Writing vague criteria such as “works correctly” |
| Test-first practices | Explain how tests can guide design and reduce defects | Treating testing as a phase at the end |
| Continuous integration | Explain why frequent integration reduces late surprises | Integrating only before release |
| Refactoring | Improve internal design without changing external behavior | Treating refactoring as optional polish forever |
| Pairing or peer review | Improve quality and shared understanding | Using it only as inspection after defects appear |
| Nonfunctional requirements | Include performance, security, reliability, usability, compliance, and maintainability | Assuming only visible features matter |
| Technical debt | Make debt visible and prioritize it responsibly | Hiding debt until velocity collapses |
Risk, Change, and Governance Checks
Risk readiness
- Can you identify technical, business, schedule, dependency, people, and external risks?
- Can you explain why agile reduces some risk through early feedback but does not eliminate risk?
- Can you select a spike, prototype, experiment, or incremental release to reduce uncertainty?
- Can you decide when risk should change backlog priority?
- Can you distinguish risk from issue?
- Can you communicate risk without creating panic or hiding uncertainty?
Change readiness
| Situation | Agile handling |
|---|---|
| New high-value request appears | Add to backlog, clarify value, prioritize, and assess impact |
| Change appears during an iteration | Protect current goal where appropriate; involve product decision-maker |
| Scope grows but date is fixed | Make trade-offs visible: reduce scope, increase capacity if realistic, change date, or accept risk |
| Compliance requirement changes | Update backlog, Definition of Done, documentation needs, and release assumptions |
| Stakeholder wants a commitment before discovery | Provide assumptions, ranges, risks, and decision points |
Governance readiness
- Explain how agile can produce useful documentation without excessive bureaucracy.
- Identify governance needs such as traceability, audit evidence, approvals, risk visibility, and financial reporting.
- Tailor artifacts to the level of risk, complexity, and organizational need.
- Avoid the false choice between “agile” and “controlled.”
- Explain how hybrid approaches can preserve adaptive delivery while meeting external constraints.
Common PMI-ACP Weak Areas and Traps
| Weak area | Why it causes misses | How to fix it |
|---|---|---|
| Memorizing terms without scenario judgment | The exam style often rewards best next action reasoning | Practice asking: “What improves value, transparency, learning, or collaboration?” |
| Confusing agile with no planning | Agile plans continuously and adapts | Review release planning, iteration planning, and rolling-wave planning |
| Treating velocity as performance management | Velocity is mainly for forecasting | Practice metric interpretation questions |
| Over-escalating | Agile favors team ownership and direct collaboration first | Escalate when outside team control, risk is material, or authority is needed |
| Ignoring product ownership | Value decisions need clear product accountability | In scenarios, identify who owns priority and acceptance |
| Accepting incomplete work | Undone work hides risk | Revisit Definition of Done and quality practices |
| Thinking all change is automatically accepted | Agile welcomes change through disciplined prioritization | Assess value, impact, timing, and trade-offs |
| Applying predictive habits too quickly | Fixed detailed plans can fail under uncertainty | Use adaptive planning and feedback loops |
| Not recognizing bottlenecks | Flow problems show up in WIP, cycle time, and CFDs | Practice Kanban and metric interpretation |
| Skipping stakeholder feedback | Feedback validates value | Review reviews, demos, prototypes, and customer collaboration |
| Over-documenting or under-documenting | Both can hurt delivery | Tailor documentation to risk, compliance, and usefulness |
| Confusing roles | Role clarity affects decisions | Review product, facilitation, team, sponsor, and stakeholder responsibilities |
Final-Week Review Checklist
Content refresh
- Review agile mindset principles and servant leadership behaviors.
- Recheck value delivery, prioritization, MVP, and backlog ordering.
- Review stakeholder engagement scenarios.
- Review team performance, conflict, coaching, and facilitation.
- Practice adaptive planning and reforecasting questions.
- Review risk, impediments, change, and escalation decision points.
- Review quality practices and Definition of Done.
- Interpret burndown, burnup, cumulative flow, velocity, WIP, lead time, and cycle time.
- Compare Scrum, Kanban, XP, Lean, and hybrid practices at a practical level.
Scenario reasoning drill
For each missed practice question, write one sentence for each:
- What is the real problem?
- Who should be involved?
- What artifact or information should be updated?
- What action improves transparency?
- What action protects value?
- What action supports team ownership?
- What answer choice was tempting but too controlling, passive, or bureaucratic?
Artifact drill
- Product vision
- Product roadmap
- Product backlog
- User stories
- Acceptance criteria
- Definition of Done
- Release plan
- Iteration backlog
- Risk list
- Impediment log
- Retrospective actions
- Information radiators
- Burndown, burnup, and cumulative flow diagrams
Final readiness signals
You are likely ready to move from review into focused practice when you can:
- Explain agile concepts without reciting definitions.
- Choose the best next action in messy stakeholder and team scenarios.
- Interpret agile metrics without blaming individuals.
- Balance value, risk, quality, and constraints.
- Identify when to collaborate, when to facilitate, when to update an artifact, and when to escalate.
- Recognize agile traps that sound decisive but reduce transparency, learning, or team ownership.
Practical Next Step
Mark each readiness area Green, Yellow, or Red. Spend your next study block on the Red and Yellow rows first, then use PMI-ACP-style scenario practice to confirm that you can apply the topics under exam conditions.