PMI-ACP sample questions — 25 answered and explained

Spikes produce knowledge, not shippable code; the real work is then built to the definition of done.

The spike has answered its question (the API works). Its code was written to learn fast, not to last. The story should now be built to the definition of done. Shipping or extending the spike, or patching it with overtime, trades long-term quality for a short-term saving.

1. Confirm the spike answered its question.
2. Recall that spike code is throwaway by intent.
3. Apply the definition of done to the real story.
4. Reject options that ship or stretch exploratory code.

Exam tip: Keep the spike's lesson; rebuild its code to the definition of done.

A timebox forces a decision point: when it ends, the team and product owner act on what was learned rather than extending by default.

The timebox exists so the product owner can weigh further investment against other work. An inconclusive spike goes back to that decision — another short timebox, a different approach or a different option. Continuing indefinitely, abandoning the engine, or building anyway each skip the decision.

1. Notice the timebox has ended.
2. Recognise the product owner decides how capacity is spent.
3. Treat 'inconclusive' as information, not success or failure.
4. Choose the option that makes a deliberate decision.

Exam tip: When a timebox ends, decide; don't drift.

Market need is validated by what target customers do with an increment — use it, pay for it, come back — not by what they or others say.

Using forecasts to place real orders and paying after the trial are both behaviour from the target customers. Praise at a review session and survey answers are opinions, and sales anecdotes are second-hand, so none of them shows the need is real.

1. Identify the target users: small retailers.
2. Separate behaviour (use, payment) from opinion (praise, surveys, anecdotes).
3. Prefer first-hand evidence from the users themselves.
4. Choose the behavioural evidence from target users.

Exam tip: Behaviour beats opinion when validating market need.

A randomized controlled comparison (A/B test) is the most reliable way to attribute a difference in behaviour to a change.

With high traffic, the team can split visitors randomly and measure trial starts for both designs at once. Sequential releases confound the result with time, while a focus group and an expert's choice rely on opinion rather than observed behaviour.

1. Note the goal: evidence about visitor behaviour.
2. Note the enabler: enough traffic to split.
3. Prefer simultaneous, random assignment over sequential tests.
4. Reject options based on opinion.

Exam tip: Split traffic randomly and run variants side by side to learn which one works.

Leaders create an environment to innovate by removing systemic barriers — such as heavy approval for small experiments — rather than working around them.

The cause of the 'safe' ideas is a monthly approval cycle for every experiment. Negotiating a fast path for small, contained experiments fixes the cause transparently. Batching or better proposals keep the delay, and running experiments secretly undermines trust.

1. Identify the cause: approval delay on every experiment.
2. Look for an option that changes the system, not the team's behaviour.
3. Keep governance for larger changes.
4. Reject options that hide work from governance.

Exam tip: Lower the cost of trying small things; keep heavy gates for big ones.

Experiments and spikes are real work: they belong in the backlog where the product owner can see and order them against other items.

The problem is hidden work competing with committed stories. Putting experiments in the backlog makes the trade-off visible and lets the product owner order them. The other options keep the work hidden, put it under someone without that authority, or drop early learning.

1. Identify the problem: invisible work using capacity.
2. Recall who orders the backlog: the product owner.
3. Make the experiments visible where trade-offs are made.
4. Reject options that hide or abandon them.

Exam tip: If it uses team capacity, it belongs in the backlog.

When an early decision is uncertain and costly to reverse, keep options open and use small experiments to decide with evidence.

Two plausible approaches, high reversal cost and little evidence: running small experiments on both is the cheapest way to make a sound choice early. Picking by familiarity or authority commits without evidence, and pausing all work for a full study is slow.

1. Note the uncertainty and the high cost of switching.
2. Prefer cheap evidence before an expensive commitment.
3. Keep both options alive briefly.
4. Decide when the experiments report back.

Exam tip: For costly, uncertain decisions, experiment on the options before committing.

Remote teams show non-verbal cues through camera use, response tone, latency and silence; a change from a person's norm matters more than the cue itself.

Two facts combine. First, the useful cue is the change from the developer's usual behaviour, which on a remote team shows in camera use and chat tone. Second, a public question that gets a closed answer has not resolved the signal, so the right move is a private follow-up rather than accepting the words. Mandating cameras and group discussions address visibility in general and not this person.

1. Identify the remote equivalents of body language: camera, tone, response style.
2. Compare against the person's normal behaviour.
3. Note that the public 'fine' contradicts the behaviour.
4. Follow up privately rather than accepting or broadcasting it.

Exam tip: On remote teams, a change in how someone shows up is the cue; check privately, not in the group.

Self-assessment output should be read for spread and patterns, not just averages; strong disagreement between members is itself a finding.

An average of 3.5 looks only slightly below the rest, but it hides a bimodal split. When half the team rates something 5 and half rates it 2, members are experiencing or defining the area differently, and that is what the team needs to talk about. Treating the average as healthy, or setting an improvement goal for the lowest area straight away, acts on a number the team does not agree on; asking the product owner to rule loses the team's own understanding.

1. Look beyond averages to the distribution of scores.
2. Recognise a split as different perceptions within the team.
3. Use the result to start a team conversation, not to reach a verdict.
4. Let the team surface what lies behind the gap.

Exam tip: In self-assessments, a wide spread of scores can matter more than a low average.

Team self-assessments are improvement tools for the team; tying them to rankings or rewards distorts the scores.

Once scores affect bonuses or rankings, teams have every reason to score themselves high, and the tool stops telling anyone the truth. Normalising, validating or anonymising the scores all keep the comparison that causes the problem. The practitioner should keep the results with the teams, as input for their own improvement.

1. Identify who the self-assessment is for: the team.
2. Predict what a reward does to self-reported scores.
3. Reject fixes that keep the ranking.
4. Keep the tool as input to the team's improvement.

Exam tip: Self-assessment scores stay honest only while they are used for the team's own improvement.

Interpreting self-assessment output means looking at trends over time and exploring significant changes with the team before acting.

Two facts decide this. Trends matter: a fall from 4 to 2 in one quarter is a significant change, unlike a steady pattern. And self-assessment results should start a conversation, not prescribe a fix, so the team and the product owner need to explore why collaboration fell. Actions for every low area lack focus; coaching only the product owner assumes the cause; re-running the survey delays a clear signal.

1. Compare the latest scores with the trend, not just with a threshold.
2. Spot the sharpest change as the most important signal.
3. Explore its cause with everyone involved before choosing actions.
4. Keep improvement focused rather than spread across every area.

Exam tip: Treat a sharp change in a self-assessment trend as a question to explore together, not a verdict.

Collective ownership means the team commits to and is accountable for a shared goal, not individuals for their own tasks.

The cause is individual ownership created by assigning stories in planning. The practitioner should help the team see the iteration goal as theirs together and work as a group on open stories. Reassigning work is the practitioner deciding for the team; individual metrics reinforce the problem; cutting scope leaves free capacity unused.

1. Find the root cause: work was owned by individuals, not the team.
2. Prefer an action that changes how the team sees ownership.
3. Avoid the practitioner directing the work.
4. Avoid measures that reinforce individual ownership.

Exam tip: Agile teams succeed or fail together: frame goals as the team's and let members swarm.

Collective ownership is undermined by individual output rewards; using velocity as a performance target makes it unreliable as a planning measure.

Two facts combine. Individual rewards for story points push developers to optimise their own numbers rather than the team's goal. Moving the same reward to team velocity looks like a fix, but rewarding velocity invites estimate inflation. Recognising the team for outcomes it delivers keeps both collective ownership and honest estimation. Complexity weighting and peer-rated bonuses keep the individual competition.

1. Ask what each incentive pushes people to optimise.
2. Spot rewards that focus on individuals instead of the team.
3. Spot rewards that turn a planning measure into a target.
4. Choose recognition tied to shared outcomes.

Exam tip: Reward the team for outcomes, never individuals for points, and never turn velocity into a target.

Backlog items are prioritized by the product owner with customers and stakeholders, using value. A scrum master facilitates; they do not decide the order.

The scrum master's role is to facilitate the product owner and stakeholders in comparing value, not to choose. Ranking by size ignores value, escalating to the sponsor skips the collaboration, and the team does not own value decisions between customer groups.

1. Identify who owns the order: the product owner, with stakeholders.
2. Identify the scrum master's role: facilitation.
3. Pick the option that brings the parties together around value.

Exam tip: The product owner orders the backlog with stakeholders; the scrum master facilitates, not decides.

Backlog items are decomposed into vertical slices: each one crosses every layer and delivers a small, usable behaviour.

Horizontal (layer) splits deliver nothing usable until all are finished, which is the symptom described. Splitting by the buyer's workflow steps gives demonstrable value each iteration. Technical tasks are a sub-level of a story, and merging back loses the benefit of decomposition.

1. Spot the symptom: no story works without the others.
2. Recognise a horizontal (layer) split.
3. Choose a split that delivers working behaviour per story.

Exam tip: Slice vertically, through every layer, so each story works and can be shown.

Common splitting patterns cut by workflow step or operation, by business rule, and by data or customer variation. Each resulting story keeps value for the user.

Pausing versus cancelling splits by operation, and monthly versus annual splits by variation. Both leave each piece usable. The database, screen and test stories are layer or activity splits that deliver no value on their own.

1. Note the need: the story is larger than one iteration.
2. Test each split: could a customer use the result on its own?
3. Keep the operation and variation splits; drop the layer and activity splits.

Exam tip: Good splits cut by operation, rule or variation; bad splits cut by layer or activity.

Planning poker: everyone reveals at once, the outliers explain, the team discusses and re-votes until estimates converge.

A wide spread signals different understandings of the work. The process asks the highest and lowest estimators to explain, then re-votes. Averaging, majority and deferring to seniority all skip the discussion that makes collective estimates reliable.

1. Notice the wide spread, with one outlier at 20.
2. Recall what planning poker does with divergent estimates.
3. Choose discussion led by the outliers, then a new vote.

Exam tip: In planning poker, divergence is information: hear the outliers, then re-vote.

Story points are a relative, unitless measure of effort, complexity and uncertainty, set by the team against reference stories.

A 5-point story is roughly five-thirds the size of a 3-point reference story for that team, whatever the hours. Converting points to hours, treating them as value, or having the product owner set them are common misunderstandings.

1. Recall what story points measure.
2. Recall who sets them and against what reference.
3. Reject options that fix them to hours, value or the product owner.

Exam tip: Story points are relative size set by the team, not hours and not value.

Feature flags (toggles) separate deploying code from releasing it to users. Code can sit in production switched off for everyone except a chosen group, so feedback starts before a public launch.

The deciding constraint is "nothing generally available before launch". A flag-controlled pilot satisfies it while giving real customer feedback within a week of deployment. Changing marketing’s cycle ignores the constraint, and demos or staging tests produce internal opinions rather than customer use.

1. Note that deployment is already weekly; the delay is in release.
2. Note the constraint: no general availability before launch.
3. Find the option that lets a small invited group use the feature now.
4. Reject options whose feedback comes only from staff.

Exam tip: Deploying is not releasing: flags let a chosen few use finished work long before the public launch.

Frequent small releases depend on technical practices such as test automation and continuous integration, which keep the product releasable without long manual checks.

The bottleneck is a slow manual check. Automating it removes the delay while keeping full coverage on every change. Testing only the riskiest areas trades coverage for speed, releasing weekly to staging keeps users on a monthly cycle so feedback is no faster, and adding testers keeps a costly multi-day step that grows over time.

1. Find the bottleneck: four days of manual regression.
2. Check the goal: weekly releases to users, at the same quality.
3. Look for a change that removes the delay without reducing coverage.
4. Reject options that test less or keep users on the old cycle.

Exam tip: Release frequency is limited by how fast you can prove nothing broke; automate that proof.

Continuous integration and automated deployment (together, continuous delivery) keep the product in a releasable state, so small increments can reach users as soon as they are done.

Continuous integration keeps every change integrated and tested; an automated pipeline makes release a push-button step. Together they let the product owner release at any time. Pairing and a definition of ready improve work quality and flow into iterations, and a quarterly plan fixes timing rather than enabling it.

1. Ask what stops a team releasing at any moment: integration problems and manual deployment.
2. Choose the practices that remove each of those.
3. Reject practices that improve other things but not releasability.

Exam tip: Continuous integration plus automated deployment keep the product releasable at any moment.

Each feedback technique suits a different question. Analytics show what happens and where; usability testing and interviews show why; split tests compare known alternatives.

The team already knows where users drop out; it needs the reason. Watching users attempt the step reveals it directly. A funnel chart repeats the "where", a broad survey asks the wrong people the wrong question, and a split test is useful only once the team has an idea worth testing.

1. Identify what is known (where users leave) and what is missing (why).
2. Match the missing piece to the technique that reveals reasons.
3. Hold comparison tests until there is a hypothesis to test.

Exam tip: Analytics tell you where; watching users tells you why; split tests tell you which.

Quantitative feedback (analytics) answers "how many" and "how often"; qualitative feedback (interviews, observation) answers "why". Good feedback plans use each for the question it fits.

The first question is a count, which usage data answers reliably. The second asks for reasons from a specific group, which short interviews with that group answer. NPS is too general, a review demo gathers opinions from attendees, and an internal focus group asks the wrong people.

1. Split the problem into its two questions.
2. Match the "how many" question to behavioural data.
3. Match the "why" question to conversations with the people who acted.
4. Reject techniques aimed at the wrong group or a different question.

Exam tip: Use data for "how many" and conversations for "why", and ask the people who actually did it.

Stakeholder feedback should be collected on a regular, short cadence that matches delivery, so each increment can be adjusted before more work depends on it.

Matching the feedback rhythm to the two-week delivery rhythm limits wasted work to one increment. A monthly report is one-way, quarterly approval of requirements still defers reaction to working product, and the stand-up is the wrong event for product feedback.

1. Compare the delivery cadence (two weeks) with the feedback cadence (quarterly).
2. Look for an option that shortens the feedback cycle to match delivery.
3. Prefer feedback on working product over documents or status reports.

Exam tip: Feedback should arrive as often as increments do; otherwise you build on guesses between reviews.

When stakeholders have little time, feedback can be collected asynchronously, for example by giving them access to each increment and an easy way to comment, rather than slowing delivery to fit their calendar.

Several options keep some feedback flowing, but only asynchronous hands-on access gives real pharmacist feedback on every increment without changing the team’s rhythm. Longer iterations slow everyone, a proxy substitutes guesses for feedback, and a video gives no hands-on experience or easy reply.

1. Note the constraint: little meeting time, but feedback wanted on every increment.
2. Separate the feedback from the meeting.
3. Prefer hands-on use by the real users over relayed views.
4. Keep the team’s delivery rhythm unchanged.

Exam tip: If stakeholders cannot come to the increment, take the increment to them and make replying easy.