PMI-ACP · Domain 1 of 4

PMI-ACP Domain 1: Mindset

Mindset is tied for the largest share of the PMI-ACP exam. It tests whether you think like an agile practitioner: experimenting early, choosing an approach that fits the problem's complexity, keeping work transparent, and making it safe for a team to raise bad news.

Exam weight
28%
Official tasks
7
Estimated questions estimate
~34
Suggested study time estimate
30–40 hrs

About 18 min read Reviewed October 2026

Overview

Mindset covers the beliefs and habits that make agile practices work rather than the practices themselves. Its seven tasks ask you to experiment early to test assumptions, apply agile values and principles (including judging whether agile suits a given situation), build a collaborative and transparent team environment, foster psychological safety, shorten feedback loops, and treat change as useful information rather than a threat.

The domain exists because teams that adopt ceremonies without the mindset end up with mini-waterfalls: two-week phases, late testing, and hidden status. PMI-ACP scenarios therefore reward the answer that creates learning, visibility and trust, not the one that adds control. Mindset is the lens for the other three domains: Leadership is how you spread it, Product is how you apply it to what gets built, and Delivery is how it shows up in daily flow and metrics.

How it's tested

Mindset items are short situational scenarios: a team, a stakeholder or an organization behaves in a way that conflicts with agile values, and you pick the BEST or FIRST response. Expect multiple-response and matching items on values, principles and complexity domains. The winning answer usually increases learning, visibility or team ownership while staying respectful of the people involved.

  • Fit the approach to complexity

    A scenario describes how certain the requirements and technology are, and you decide whether an adaptive, predictive or hybrid approach fits, often using Stacey or Cynefin reasoning.

  • Make it safe and visible

    Someone hides a problem, blames a colleague, or status lives in one person's head, and you choose the response that surfaces information without punishment.

  • Test before you build big

    A team or sponsor wants to commit heavily to an unproven idea, and you pick the smallest experiment, prototype or minimum viable product (MVP) that tests the riskiest assumption.

Reasoning it through

A product owner wants the team to build a full customer portal over six months because the sponsor is sure customers want it. Ask what is uncertain: customer demand, not technology. The best answer is a small experiment, such as a clickable prototype or a single-feature release to a pilot group, that tests demand within weeks. Building everything first, or writing a detailed requirements document, delays the learning the scenario is really about.

Tasks 7

Official tasks from the PMI outline, in outline order.

1.1 Experiment EarlyValidate solutions and market need with small, early increments.
What it means
Build the smallest thing that can test whether a solution works or whether anyone wants it, and create conditions where trying ideas and learning from failed ones is normal.
What to understand
An experiment has a hypothesis, a cheap test, and a decision rule set in advance. A minimum viable product (MVP) tests the riskiest business assumption, a spike tests a technical unknown, and a prototype tests usability; all three exist to buy information before large investment.
How it shows up
A sponsor or team wants to commit months of work to an untested idea, and the best answer runs a time-boxed spike, prototype or MVP first.
Common confusion
Treating an MVP as a cut-down first release to ship on a date; its purpose is learning, so a failed MVP that kills a bad idea is a success.
1.2 Embrace Agile MindsetApply agile values and principles and judge where agile fits.
What it means
Use the four values and twelve principles of the Agile Manifesto as decision rules, classify situations with complexity models, read agile suitability assessments, and combine agile models where that fits the context.
What to understand
Complexity models such as the Stacey matrix (agreement on requirements versus certainty of technology) and Cynefin (clear, complicated, complex, chaotic) tell you when to probe and adapt and when a plan-driven approach is acceptable. A suitability filter scores culture, team and project factors to suggest agile, hybrid or predictive.
How it shows up
A scenario gives you clues about requirement stability and technical certainty and asks which approach or model fits, or which manifesto value a behavior violates.
Common confusion
Reading 'over' in the manifesto as 'instead of'; documentation, contracts, plans and processes still have value, just less than the items on the left.
1.3 Promote Collaborative Team EnvironmentVision, working agreements, high-performing teams and fewer silos.
What it means
Help the team agree on a shared vision and working agreements, grow toward high performance, use retrospectives to improve how they work, break down functional silos, and choose ways to coordinate with other teams.
What to understand
Working agreements are created by the team, not issued to it, and are revisited when they stop working. Tuckman's stages (forming, storming, norming, performing) explain why a new team needs more facilitation, and cross-team coordination options range from a scrum of scrums to shared backlogs and communities of practice.
How it shows up
Team members work in parallel silos or keep breaking an unspoken norm, and the best answer is a facilitated team conversation that produces or revisits a working agreement.
Common confusion
Assuming the agile practitioner writes the team charter or ground rules; the practitioner facilitates and the team owns them.
1.4 Build TransparencyMake status, progress and learning visible to everyone.
What it means
Put the real state of work where anyone can see it, set up feedback loops inside the team, and plan communication that works for both co-located and distributed members.
What to understand
Information radiators (task boards, burn charts, cumulative flow diagrams) replace status reports by making progress self-service. For distributed teams, transparency depends on a single digital source of truth, overlapping working hours and recorded decisions, since hallway conversations exclude remote members.
How it shows up
Stakeholders keep asking for status or a remote member misses decisions, and the best answer makes information visible in a shared place rather than adding more reports or meetings.
Common confusion
Thinking transparency means showing only good news or polished data; a board that hides blocked work is worse than no board.
1.5 Foster Psychological SafetyCreate a no-blame climate where people speak up.
What it means
Build an environment in which team members can admit mistakes, ask questions, give honest feedback and challenge the status quo without fear of embarrassment or punishment.
What to understand
Psychological safety, as described by Amy Edmondson, is a shared belief that the team is safe for interpersonal risk-taking. Blameless retrospectives focus on the system, dialogue explores ideas together while debate tries to win, and leaders build safety by modeling fallibility and thanking people for raising problems.
How it shows up
A team member hides a defect or stays silent in meetings after being criticized, and the best answer addresses the climate privately and through team norms, not with a warning or a new approval step.
Common confusion
Equating psychological safety with avoiding conflict or lowering standards; safe teams argue more openly about work while holding high expectations.
1.6 Shorten Feedback LoopsGet stakeholder input early and often to maximize value.
What it means
Involve stakeholders from the start and arrange work so the time between doing something and learning whether it was right keeps shrinking, using approaches such as design thinking and lean startup.
What to understand
Feedback loops nest: pairing and test-driven development give feedback in minutes, continuous integration in hours, daily standups in a day, and reviews and releases in weeks. Lean startup's build-measure-learn loop and design thinking's empathize-define-ideate-prototype-test cycle both exist to learn before scaling.
How it shows up
A team discovers late that a feature missed the user's need, and the best answer adds an earlier, shorter loop such as showing a prototype or involving users in refinement.
Common confusion
Believing a longer iteration produces better feedback because more is finished; shorter loops reduce the cost of being wrong.
1.7 Embrace ChangeAdapt plans, skills and the product as information arrives.
What it means
Encourage a growth mindset, adapt processes when priorities shift, build cross-skills so the team can absorb change, and adjust the product in response to feedback.
What to understand
Agile welcomes changing requirements, even late, but the team manages change through the backlog: new work is prioritized against existing work, and the iteration goal is protected unless the product owner decides the goal is obsolete. T-shaped skills make reprioritization practical because fewer items wait on one specialist.
How it shows up
A stakeholder requests a change mid-iteration, and the best answer routes it to the product owner to prioritize in the backlog rather than refusing it or forcing it into the current iteration.
Common confusion
Reading 'welcome change' as 'accept every change immediately'; change is welcomed into the backlog and sequenced by value.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • Agile Manifesto values

    Four value statements favor individuals and interactions, working software, customer collaboration and responding to change over processes and tools, comprehensive documentation, contract negotiation and following a plan.

    Remember
    The items on the right still have value; the manifesto says the items on the left are valued more.
    Tested as
    Items describe a behavior and ask which value it supports or violates, so you must map actions to the correct pair.
    Trap
    Choosing an answer that discards documentation or planning entirely, which the manifesto never recommends.

  • Stacey complexity matrix

    Plots agreement on requirements against certainty of technology; high agreement and high certainty is simple, both low is chaotic, and the broad middle band is complex, where empirical, adaptive approaches fit best.

    Remember
    The further a project sits from the simple corner on either axis, the stronger the case for iterative, adaptive delivery.
    Tested as
    Scenarios describe requirement volatility and technical novelty and ask which approach fits.
    Trap
    Picking agile for a well-understood, stable, repeatable project just because agile is the exam's theme.

  • Cynefin framework

    Dave Snowden's sense-making model has clear (sense-categorize-respond), complicated (sense-analyze-respond), complex (probe-sense-respond) and chaotic (act-sense-respond) domains, plus confusion when you do not know which applies.

    Remember
    Complex problems need safe-to-fail probes because cause and effect are only visible in hindsight.
    Tested as
    A scenario describes a situation and asks for the first move: analyze with experts, run experiments, or act to stabilize.
    Trap
    Sending a complex problem to experts for more analysis, which is the response for the complicated domain.

  • Minimum viable product (MVP)

    The smallest product version that lets the team test a key hypothesis with real users and collect validated learning with the least effort.

    Remember
    An MVP is measured by what it teaches, not by how much it delivers.
    Tested as
    Appears when a sponsor wants a large build on an unproven market assumption.
    Trap
    Confusing the MVP with the minimum marketable feature (MMF), the smallest piece that delivers value customers will pay for or use.

  • Spike

    A short, time-boxed piece of research or prototyping that reduces a technical or design uncertainty so the team can estimate or decide.

    Remember
    A spike produces knowledge, not shippable code, and is time-boxed so it cannot grow into a hidden project.
    Tested as
    The likely answer when a team cannot estimate a story because of an unfamiliar technology.
    Trap
    Padding the estimate or splitting the story arbitrarily instead of spending a small, fixed effort learning.

  • Psychological safety

    A shared belief that the team is safe for interpersonal risk-taking, so people raise mistakes, questions and dissent without fear.

    Remember
    It is built by how leaders react to bad news, especially the first time someone admits a mistake.
    Tested as
    Behind many scenarios where people stay quiet, hide defects or agree too quickly.
    Trap
    Treating it as comfort or harmony; safe teams disagree more openly, not less.

  • Information radiator

    A large, visible, always-current display of work status, such as a task board or burndown chart, placed where the team and stakeholders see it without asking.

    Remember
    It must be updated by the team as part of daily work, or it becomes decoration.
    Tested as
    The preferred answer when stakeholders lack visibility or keep requesting status meetings.
    Trap
    Choosing a detailed weekly status report, which pushes information on a schedule rather than making it self-service.

  • Working agreements

    Explicit norms the team creates for how it works together, such as core hours, response times, definition of ready and how decisions are made.

    Remember
    The team creates and revises them; the facilitator helps and reminds.
    Tested as
    The answer when recurring friction comes from unstated expectations.
    Trap
    Having the agile practitioner or manager write the rules and hand them over.

  • Tuckman's stages of team development

    Teams move through forming, storming, norming and performing, with adjourning at the end, and can regress when membership or goals change.

    Remember
    Leadership style shifts from directing in forming to coaching in storming, supporting in norming and delegating in performing.
    Tested as
    Scenarios describe conflict or confusion in a new or changed team and ask what is happening or what to do.
    Trap
    Treating storming as a failure to stop rather than a normal stage to facilitate.

  • Build-measure-learn

    The lean startup loop in which a team builds the smallest test, measures real behavior, and learns whether to persevere or pivot.

    Remember
    Plan the loop backward: decide what you need to learn, then what to measure, then what to build.
    Tested as
    Used when the scenario asks how to reduce uncertainty about customer demand.
    Trap
    Measuring vanity metrics such as page views that cannot support a pivot or persevere decision.

  • Growth mindset and T-shaped skills

    A growth mindset treats ability as developed through effort and feedback; T-shaped people have deep skill in one area and working skill in several others.

    Remember
    Cross-skilling reduces single points of failure and lets the team absorb shifting priorities.
    Tested as
    Appears when one specialist is a bottleneck or a team resists new work types.
    Trap
    Hiring another specialist as the first response instead of encouraging pairing and cross-training.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Cynefin domains and the right first move

ConceptMeaningKey differenceCommon trap
Clear Cause and effect are obvious; best practice exists Sense, categorize, respond Over-engineering a routine problem with experiments
Complicated Cause and effect are knowable through expert analysis Sense, analyze, respond Running experiments when an expert can answer the question
Complex Cause and effect are clear only in hindsight Probe, sense, respond with safe-to-fail experiments Commissioning more upfront analysis as if the problem were complicated
Chaotic No discernible cause and effect; crisis Act first to stabilize, then sense and respond Holding a workshop while the production outage continues

MVP vs. MMF vs. spike vs. prototype

ConceptMeaningKey differenceCommon trap
MVP Smallest product to test a business hypothesis with real users Goal is validated learning Judging it by revenue or completeness
MMF Smallest feature set that delivers usable value to customers Goal is releasable value Using MMF and MVP as synonyms
Spike Time-boxed research on a technical or design unknown Output is knowledge to estimate or decide Letting the spike run without a time-box
Prototype Mock-up or partial model to explore usability or design Tests how a solution looks or works, often thrown away Shipping a throwaway prototype as production code

Dialogue vs. debate vs. discussion

ConceptMeaningKey differenceCommon trap
Dialogue Shared exploration to understand assumptions and build meaning Goal is mutual understanding Cutting it short to reach a decision too early
Debate Argument in which each side tries to win Goal is winning a position Mistaking a forceful debate for healthy team collaboration
Discussion Narrowing options toward a decision Converges after dialogue has widened understanding Starting with discussion before people understand each other's views

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Plan harder for uncertainty

    What candidates pick
    Run a detailed requirements workshop to remove the uncertainty before starting.
    Why it looks right
    Upfront analysis feels responsible and is how many candidates were trained.
    Why it's wrong
    When customers cannot say what they want until they see something, analysis cannot remove the uncertainty; only a quick probe with real users can.

    Clue to watch for The scenario says stakeholders are unsure, the market is new, or requirements keep shifting after each demo.

  2. Agile for everything

    What candidates pick
    Recommend a fully adaptive approach for a stable, repeatable, well-specified project.
    Why it looks right
    The exam is about agile, so agile looks like the safe answer.
    Why it's wrong
    The ECO expects you to read suitability tools and complexity models; a simple, certain project may fit predictive or hybrid delivery better.

    Clue to watch for Requirements are fixed by regulation, the technology is proven, and the team has done the same work before.

  3. Punish the messenger

    What candidates pick
    Escalate or formally warn a developer who hid a defect until the demo.
    Why it looks right
    Hiding defects is genuinely harmful, so a firm response seems justified.
    Why it's wrong
    Punishment teaches the whole team to hide problems better; the better response explores why it felt unsafe to raise the issue and fixes that through blameless norms.

    Clue to watch for The scenario mentions earlier criticism, a manager who reacts harshly, or a team that has gone quiet.

  4. Status report as transparency

    What candidates pick
    Send a more detailed weekly status email to anxious stakeholders.
    Why it looks right
    It responds directly to the request and looks proactive.
    Why it's wrong
    Reports are periodic, filtered and costly; an information radiator or shared board gives stakeholders the same truth the team sees, whenever they want it.

    Clue to watch for Stakeholders keep interrupting the team for updates or say they were surprised by progress.

  5. Change goes straight into the iteration

    What candidates pick
    Add an urgent stakeholder request to the current iteration because agile welcomes change.
    Why it looks right
    It sounds like embracing change and pleasing the customer.
    Why it's wrong
    Change is welcomed into the product backlog, where the product owner prioritizes it; disrupting a committed iteration goal is reserved for when the goal itself becomes obsolete.

    Clue to watch for The request arrives mid-iteration and does not invalidate the current iteration goal.

  6. Leader writes the team rules

    What candidates pick
    The agile practitioner drafts ground rules to stop recurring friction.
    Why it looks right
    It is fast and clear.
    Why it's wrong
    Rules the team did not create carry little ownership; facilitating the team to write a working agreement builds commitment and self-management.

    Clue to watch for The friction comes from unstated expectations such as meeting punctuality or response times.

Answer framework

For any Mindset scenario, use these steps to find the answer that reflects how an agile practitioner thinks.

  1. Identify what is uncertain or hidden in the scenario: customer need, technology, team behavior, or the real status of the work.
  2. Place the situation on a complexity model and decide whether it needs expert analysis, an experiment, or immediate stabilization.
  3. Prefer the response that makes information visible or creates learning quickly, such as a radiator, prototype, spike or short feedback loop.
  4. Check the human side: choose actions that build trust and safety and let the team own its agreements instead of imposing control.
  5. Reject options that protect the plan, punish people, add approval layers, or let the leader decide what the team should decide.

Practice question

A team is asked to build a new mobile ordering feature. The sponsor believes customers want it, but no customer research exists, and the technology is familiar to the team. What should the agile practitioner recommend FIRST?

Want more like this? The PMI-ACP practice test has questions for every domain.

Checklist

0 of 12

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start Mindset by rereading the Agile Manifesto values and principles until you can name the principle behind a behavior without looking. Then learn the Stacey matrix and Cynefin well enough to classify a scenario from two or three clues, because many Mindset items reduce to that judgment.

Give the most time to the people-side tasks: psychological safety, collaborative team environment and transparency. These are commonly underestimated because they sound like common sense, yet the exam separates options by subtle differences, such as facilitating an agreement versus issuing one, or radiating information versus reporting it. Study Tuckman's stages and the difference between dialogue and debate alongside them.

For Experiment Early and Shorten Feedback Loops, practice deciding which experiment fits: MVP for market doubt, spike for technical doubt, prototype for usability doubt. Write your own one-line scenarios for each and check whether you can tell them apart.

Afterwards, move to Leadership, which applies these beliefs to coaching and conflict, then drill mixed situational questions. When reviewing misses, ask which agile value the correct answer protected; that habit transfers to every domain.

FAQ

How much of the PMI-ACP exam is Mindset?

Mindset is 28% of the exam, tied with Delivery as the largest domain. Our planning estimate is about 34 of the 120 items, but PMI does not publish per-domain question counts.

Do I need to memorize the twelve agile principles?

You need to recognize them in action rather than recite them. Questions describe behavior, such as delivering frequently or welcoming late change, and expect you to see which principle applies.

Are Cynefin and the Stacey matrix really tested?

The ECO's Embrace Agile Mindset task explicitly includes classifying scenarios with complexity models and interpreting agile suitability tools, so expect to judge whether a situation needs analysis, experimentation or a plan-driven approach.

What is the difference between an MVP and a spike?

An MVP tests a business or market hypothesis with real users. A spike is a time-boxed investigation of a technical or design unknown, usually so the team can estimate or choose an approach.

How do Mindset questions differ from Leadership questions?

Mindset asks what an agile practitioner should believe and prioritize in a situation, such as learning over certainty or visibility over reporting. Leadership asks how you influence others to act that way through coaching, empowerment and conflict facilitation.

Does agile mean I should always reject documentation and plans?

No. The manifesto values working software and responding to change more than documentation and plans, but it states that the latter still have value. Options that discard them entirely are usually wrong.

How long should I study Mindset?

Our planning estimate is 30–40 hours within a 120-hour total plan, weighted toward practice scenarios rather than reading, since the domain is tested through judgment calls.

Other Project Management certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 1 knowledge

You have covered agile values, complexity models, early experiments, transparency and psychological safety. Test whether you can pick the mindset-driven answer when two options both sound agile.

Take the PMI-ACP practice test Check your PMI-ACP readiness

Keep going