The PMI Agile Certified Practitioner (PMI-ACP) is the agile certification that refuses to belong to one method. Where a Scrum certification tests Scrum and a Kanban certification tests Kanban, the PMI-ACP deliberately spans Scrum, Kanban, Lean, Extreme Programming and more, and it rewards the practitioner who can reach for the right approach rather than the one who has memorised a single playbook. PMI rebuilt the exam with its November 2024 Examination Content Outline, collapsing the old seven-domain structure into four domains: Mindset, Leadership, Product and Delivery. This guide is a full self-study course. It explains what each domain is really testing, teaches the agile thinking the questions hinge on, walks through the frameworks you are expected to recognise, and turns all of it into a study plan. It is original teaching material only. It contains no real or simulated exam questions, and you should confirm the current outline and eligibility against PMI’s own certification page before you book.
Chapter 1: Exam overview and how to use this guide
What the PMI-ACP actually measures
The PMI-ACP measures whether you can think and act like an experienced agile practitioner across more than one way of working, not whether you can recite the rules of any single framework. This is the defining feature of the credential and the single most important thing to internalise before you study: the exam is framework-agnostic. A question may describe a team using a flow-based, pull system one moment and a timeboxed, sprint-based team the next, and it expects you to recognise both and reason about each on its own terms. People who prepare for it as a Scrum exam with extra topics tend to struggle, because the test is built to reward breadth.
The current exam is 120 questions in three hours, of which 100 are scored and 20 are unscored pretest items mixed in invisibly. It is taken at a Pearson VUE test centre or via online proctoring. PMI does not publish a fixed passing percentage. Your result is judged against a psychometric standard set through expert review rather than a simple “70% correct” line, so the practical goal is to be consistently strong across all four domains rather than to chase a single number.
The four domains and their weights
The November 2024 outline organises everything into four domains with these weights: Mindset at 28%, Leadership at 25%, Product at 19%, and Delivery at 28%. Those weights are your study budget. Mindset and Delivery are the two heaviest at 28% each and together account for more than half the exam, so they deserve the most time, with Leadership close behind and Product the smallest but still substantial. If any prep material you pick up is built around seven domains (the old structure had headings such as “Agile Principles and Mindset”, “Value-Driven Delivery” and “Adaptive Planning”), it predates the current exam and you should set it aside.
Eligibility and how to use this course
Unlike the entry-level CAPM, the PMI-ACP assumes you already work in agile environments. You need a secondary education, real experience working on agile teams, and a number of contact hours of agile-practices training to qualify. PMI realigned the eligibility requirements with the 2024 outline, so confirm the exact current experience and training-hours figures on PMI’s certification page rather than relying on older numbers, and keep accurate records since PMI can audit an application. Read the four domain chapters in order, because Mindset underpins everything that follows and Leadership, Product and Delivery are best understood as that mindset applied to people, to value, and to flow. Treat the bold terms as a checklist you should be able to explain in a sentence and place in the right domain.
Chapter 2: The Mindset domain (28%)
The Mindset domain is one of the two largest, and it is the foundation the other three rest on. It is about why agile works, not which ceremony happens when. Almost every harder question elsewhere on the exam can be reasoned through if your agile mindset is solid, which is why this is the highest-leverage domain to master first.
What it is
Mindset covers agile values and principles, creating a safe and collaborative environment, and adapting your approach to the context in front of you. The anchor is the Agile Manifesto: its four values prefer individuals and interactions over processes and tools, working software (or working solutions) over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The Manifesto is careful to say there is value in the items on the right, but more in the items on the left, and that nuance matters. The twelve principles behind the Manifesto, things like delivering valuable software frequently, welcoming changing requirements even late, and reflecting regularly on how to become more effective, are the practical expansion of those values.
Why it matters
The exam is full of situations where two responses are technically allowed but only one reflects the agile mindset. A team is told a requirement has changed late in development. A plan-driven instinct treats this as a problem to be resisted through change control; the agile principle is to welcome it because it gives the customer a competitive advantage. The Mindset domain is what tells you which instinct the exam rewards. It also frames “adapting to context”, the idea that agile is not one fixed process but a set of values you tailor, which is why the same scenario can have different best answers depending on the team and the work described.
How to study it
Do not memorise the twelve principles as a list to recite. Instead, for each principle, invent a short situation where it would change a decision, so the principle becomes a lens rather than a slogan. Pay particular attention to psychological safety and a collaborative environment, because a large share of Mindset and Leadership questions reward the answer that makes it safe for the team to raise problems, experiment, and fail without blame. Connect every later topic back to here: when you learn a Kanban practice or a Scrum event in the Delivery chapter, ask which Manifesto value or principle it serves.
Common pitfalls
The classic trap is answering as a traditional, plan-driven manager who values predictability and documentation above adaptation, which contradicts the Manifesto. A second trap is treating “agile” as a synonym for “no planning” or “no documentation”; the Manifesto values planning and documentation, it just values responding to change and working solutions more. A third is forgetting that agile values are deliberately weighted rather than absolute, so an answer that throws out all process or all documentation is usually too extreme to be right.
Chapter 3: The Leadership domain (25%)
The Leadership domain is the third-largest and is where the agile mindset meets people. Its through-line is servant leadership: the agile leader exists to enable, coach and unblock the team, not to direct and control it. When two leadership answers both look reasonable, the one that empowers the team and serves its effectiveness is almost always the stronger choice.
What it is
Leadership covers servant leadership, coaching and facilitation, and collaborating with stakeholders. A servant leader removes impediments, protects the team from disruption, grows people’s capabilities, and creates the conditions for self-organisation, rather than assigning tasks and policing them. Coaching is helping the team and individuals find their own answers through questions and feedback instead of supplying solutions. Facilitation is running collaborative sessions, retrospectives, planning, decision-making, so the group does its best thinking, with the facilitator staying neutral on content. Stakeholder collaboration is the agile preference for frequent, direct, face-to-face engagement and visible progress over formal status reporting at a distance.
Why it matters
The leadership style the exam rewards is the opposite of command-and-control, and many questions are written precisely to test whether you reach for the empowering option. When a self-organising team is deciding how to do its work, the agile leader does not step in with the answer; they ask questions, offer to remove a blocker, or let the team decide. When a stakeholder is disengaged or surprised, the agile move is to increase direct collaboration and transparency, for instance inviting them to a review or radiating information, rather than escalating or generating a heavier report. Knowing that servant leadership is the default lets you eliminate the controlling and the avoidant options quickly.
How to study it
Build the habit of asking, for every people scenario, “what would a leader who serves the team and trusts it to self-organise do here?”. Learn the distinction between coaching, mentoring, facilitating and directing, because the exam sometimes hinges on choosing the lightest-touch intervention that still helps: coaching draws the answer out, mentoring shares experience, facilitating enables the group, and directing (telling people what to do) is the last resort in agile. Study information radiators, big visible charts and boards, as the agile answer to communication and transparency, since making work visible is a recurring theme that sits across Leadership and Delivery.
Common pitfalls
The biggest trap is the command-and-control answer where the leader makes the team’s decisions or assigns its work; in an agile context this undermines self-organisation and is usually wrong. A related trap is the escalate-first instinct, jumping to a manager or sponsor before engaging the people involved, when the agile pattern is to collaborate directly first. A third is confusing the servant-leader role with a passive one: serving the team is active work, removing impediments, coaching, and protecting focus, not standing back and doing nothing.
Chapter 4: The Product domain (19%)
The Product domain is the smallest of the four but it is where agile’s economic logic lives: the point of all this iteration is to deliver value to the customer early and often. Do not skip it because of its weight; its concepts also underpin Delivery.
What it is
Product covers value-driven delivery, backlog management and prioritisation, and a relentless customer and product focus. Value-driven delivery means sequencing work so the highest-value items are built first, so that even a partly finished product has delivered real benefit. The backlog is the single, ordered list of everything that might be built, and prioritisation is the ongoing act of keeping it ordered by value as understanding changes. The customer or product owner voice drives what “valuable” means, and the team builds toward a clear product vision and goal rather than a fixed, frozen specification.
Why it matters
Agile assumes you cannot know everything up front, so the safest way to maximise value is to deliver the most valuable slice, learn from it, and re-prioritise. The exam tests whether you reason from value rather than from completeness: when there is not time to do everything, the agile answer is to prioritise the highest-value work and deliver that, not to extend the deadline to finish a fixed scope. It also tests an understanding that scope in agile is expected to evolve; reordering or changing lower-priority backlog items is normal and healthy, not a failure of planning.
How to study it
Learn the common prioritisation techniques as reasoning tools rather than acronyms to recall: ordering by business value or value-to-effort ratio, MoSCoW (Must, Should, Could, Would-not-this-time), and the idea of deferring decisions until the last responsible moment so you decide with the most information. Understand a minimum viable product (MVP) as the smallest releasable thing that delivers value and produces learning, and connect it to incremental delivery. Tie everything back to the voice of the customer and critical-to-quality needs: the product exists to satisfy real customer outcomes, and a feature nobody values is waste no matter how well built.
Common pitfalls
A frequent trap is preferring scope completeness over value, choosing to deliver everything late rather than the most valuable part on time. Another is treating the backlog as a frozen contract; in agile it is meant to be reordered and refined continuously. A third is forgetting whose judgement decides priority: it is the product owner or customer voice, informed by the team, not the loudest stakeholder or the team’s own preference for interesting work.
Chapter 5: The Delivery domain (28%)
The Delivery domain is tied for largest at 28%, and it is the most hands-on: how agile teams actually get work done, sustain a healthy pace, measure progress, and improve. Because it is framework-agnostic, this is where your fluency across Scrum, Kanban and Lean is tested most directly.
What it is
Delivery covers iterative delivery and flow, team performance, and continuous improvement with metrics. Iterative and incremental delivery means producing working increments in short cycles and refining them, rather than one big delivery at the end. Flow is the Kanban-flavoured idea of moving work smoothly through the system by visualising it, limiting work in progress (WIP), and managing bottlenecks, so that less is started and more is finished. Team performance covers a high-functioning, self-organising team, while continuous improvement is the discipline of regularly inspecting how the team works and adapting, classically through retrospectives.
Why it matters
Many Delivery questions reward the answer that delivers value sooner, makes work visible, or reduces work in progress, because those are the levers agile uses to manage delivery empirically. If a team is overloaded and finishing little, the flow-based answer is to limit WIP and finish current work before starting more, not to start everything at once. If progress is unclear, the agile move is to use a visible, empirical metric rather than a subjective status. This domain also tests whether you treat improvement as continuous: the strong answer to “how do we get better?” is to inspect and adapt regularly, not to wait for a post-project review.
How to study it
Get comfortable with agile metrics and what each tells you. Velocity is the amount of work a team completes per iteration, used to forecast, not to compare teams or to pressure them. Burndown and burnup charts show work remaining or completed against time. Cycle time (how long an item takes from start to finish) and lead time (from request to delivery) measure flow and predictability in pull systems. A cumulative flow diagram reveals bottlenecks and growing WIP. Learn the Kanban core practices, visualise the workflow, limit WIP, manage and measure flow, make policies explicit, improve collaboratively, alongside the Scrum mechanics from the next chapter, and notice that both serve the same goals of transparency and fast feedback. Understand the retrospective deeply as the engine of continuous improvement.
Common pitfalls
The classic flow trap is favouring high utilisation, keeping everyone busy by starting lots of work, when agile favours finishing work and limiting WIP even if that means some idle capacity. A measurement trap is misusing velocity as a productivity target or a cross-team comparison, when it is only a team’s own forecasting aid. A third trap is treating improvement as a one-off; the agile answer is almost always to build inspection and adaptation into the regular rhythm.
Chapter 6: Frameworks, methods, and choosing between them
Because the PMI-ACP is method-neutral, you must recognise the main agile frameworks and, more importantly, reason about when each fits. The exam does not ask you to be a certified expert in any one, but it does expect you to know their vocabulary and intent and to choose appropriately for a described situation.
Scrum
Scrum is the most common framework and the one most likely to appear by name. It uses fixed-length iterations called sprints, three accountabilities (a product owner who owns and orders the backlog to maximise value, a scrum master who serves the team and its process, and developers who build the increment), and a set of events: sprint planning, the daily scrum, the sprint review, and the sprint retrospective. Its artifacts are the product backlog, the sprint backlog, and the increment. Scrum suits work that can be organised into regular timeboxes with a clear product owner and a goal per sprint.
Kanban and Lean
Kanban is a flow-based method rather than a timeboxed one. It visualises work on a board, limits work in progress, and optimises the smooth flow of items through the system, making it a strong fit for continuous streams of work such as support or operations where priorities shift constantly. Lean thinking, which underpins much of agile, focuses on maximising customer value while eliminating waste, anything that does not add value, and on principles such as deferring decisions and optimising the whole rather than local parts. Kanban is in many ways Lean applied to knowledge work.
Extreme Programming and the spectrum
Extreme Programming (XP) contributes the technical practices that make frequent delivery sustainable: pair programming, test-driven development, continuous integration, refactoring, and a focus on simple design. Where Scrum and Kanban describe how work is organised, XP describes engineering disciplines, and many teams combine XP practices with a Scrum or Kanban structure. The practical lesson the exam rewards is that these are not rivals to pick between dogmatically but a toolkit to combine: a question that describes shifting priorities and a continuous flow of requests leans Kanban, one that describes fixed iterations and a product goal leans Scrum, and one that asks how to keep quality high while delivering often points to XP-style technical practices. Reasoning from the situation to the method, rather than forcing one framework onto everything, is exactly the breadth the credential is built to reward.
Chapter 7: Study plan and timeline
With the four domains and the frameworks understood, the remaining task is pacing so that the two heaviest domains and the cross-framework breadth get the time they need. Three things drive the plan: the eligibility gate, the domain weights, and the need to practise judgement across methods rather than cramming definitions.
Clear the eligibility gate
Before you book, make sure you meet the experience and agile-training requirements and have your contact hours of agile-practices training arranged, since these are required to apply and the training itself covers much of the content. Confirm the current required hours and experience on PMI’s certification page rather than relying on older figures, and treat the training as part of your preparation, not a separate box to tick. Keep accurate records of the experience you claim, because PMI can audit an application.
Allocate time by domain weight
Spend your study hours roughly in proportion to the weights: the most on Mindset (28%) and Delivery (28%), then Leadership (25%), then Product (19%). Study Mindset first because it underpins the others, and carry the cross-framework view through every domain rather than learning Scrum and then bolting on the rest. A reasonable total for someone already working in agile is around 60 to 90 hours over eight to twelve weeks part-time; budget more if your agile experience is thin or your training hours are not yet done.
Choose a timeline
A balanced eight-week plan suits most experienced practitioners: weeks one to two on Mindset, weeks three to four on Delivery (studied across Scrum, Kanban and Lean), weeks five to six on Leadership, week seven on Product, and week eight on full-length timed practice and review. With strong agile experience you can compress this into roughly six weeks at a higher weekly intensity, leaning hard on practice in the final stretch. If you lack experience or training hours, build those first, because they are required to qualify and because the understanding they create is what the exam actually tests. To turn whichever timeline you choose into dated weeks for your own start date, use the free study-plan generator.
Build cross-framework judgement throughout
Move from reading to answering scenario questions as soon as you have covered a domain, and each time make yourself say which framework the scenario implies and why your chosen answer fits the agile mindset. The habit you are building is recognising, under time, whether a situation is flow-based or timeboxed, whether the strong move serves the team or controls it, and whether it delivers value sooner. If you are still deciding between this and a broader project credential before committing, the PMP vs PMI-ACP comparison lays out the difference in scope and agile focus.
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last week or two, shift from topic study to full-length, timed practice, and treat each session as a diagnosis rather than just a score. Break your results down by domain and look hardest at Mindset and Delivery, since they carry the most marks, and review the reasoning behind every miss: was it a knowledge gap, or did you pick the controlling or plan-driven answer when the agile one was on offer? Aim to be consistently comfortable across all four domains on fresh questions before you book. Make sure every piece of prep you are using reflects the current four-domain outline; older seven-domain material will mislead you on emphasis.
Eligibility and the application
The application has to clear before the exam matters. You need a secondary education, experience working on agile teams, and the required contact hours of agile-practices training, with the exact current figures confirmed on PMI’s site since they changed with the 2024 outline. Record your projects, roles and training accurately as you prepare, because PMI may audit what you claim and a clean record removes a source of late stress.
Exam day and format
On the day, the exam is 120 questions in three hours (100 scored and 20 unscored, mixed in so you cannot tell which is which), taken at a Pearson VUE centre or online-proctored, and you will need government-issued identification. There is no published pass percentage; results are measured against a psychometric standard, so the goal is steady strength everywhere rather than a single target score. Pace yourself at roughly a minute and a half per question, flag anything that needs a second look and move on, and apply the reasoning you practised: identify whether the scenario is flow-based or timeboxed, prefer the answer that serves the team and delivers value early, and reject the command-and-control or rigid, plan-driven options. Having practised at full length and across frameworks, the breadth that defines this credential will feel like an advantage rather than a surprise.