PMI-ACP common mistakes
PMI-ACP · Understand the traps and how to avoid them.
Choosing the option that restores control - 'build a detailed plan for the remaining work', 'raise a change request', 'obtain sponsor sign-off', 'document the risk in the register' - whenever the scenario is uncertain or changing, even when the scenario is clearly iterative.
Most candidates arrive with predictive project management training or habits, where uncertainty is answered with more upfront planning, formal approval, and documentation. Under time pressure the mind reaches for the most familiar control mechanism rather than the empirical one.
What to do instead
Before answering, test each option against two filters: does it keep the decision with the team, and does it generate fast feedback rather than certainty? Options that shrink transparency or delay feedback until approval are almost always wrong on an Agile exam.
Selecting answers where the coach/Scrum Master allocates tasks, resolves every disagreement personally, or takes the work off the team's hands ('the Scrum Master should reassign the task', 'the team lead should protect the team from all stakeholder contact').
Servant leadership is easily misread as either permissiveness or 'I do the admin and shield the team', and many candidates equate strong leadership with visible direction-setting. The exam instead tests leadership that increases the team's autonomy.
What to do instead
Prefer options where the team diagnoses, decides, and commits, and the leader removes impediments, teaches, and facilitates. Shielding the team from all stakeholder contact is a warning sign; enabling direct, informed contact is the correct pattern.
Picking options that finish the full specified scope, gold-plate a feature, or produce comprehensive documents before release, rather than options that slice out the highest-value increment and get it into users' hands early.
Candidates unconsciously optimize for 'completion' and thoroughness, which feels like quality, instead of optimizing for value realized per unit of time. The cost of delay and the option value of early feedback are not intuitive.
What to do instead
When a question asks what to do next or how to sequence work, rank options by earliest realization of business value and earliest feedback: thin vertical slices, MVP, deferring low-value items, and stopping work that no longer pays for itself.
Treating velocity or story points as a productivity or performance measure - using them to compare teams, to report individual performance, to promise a delivery date, or to decide who gets a bonus.
Velocity is the most visible number in an agile team, and organizations reward candidates for numbers they can report upward. The distinction between a planning aid with team-specific, relative units and a productivity metric is subtle and frequently glossed over in study material.
What to do instead
Anchor the rule: story points are relative and team-specific, velocity is a forecasting aid for that one team only. If a question involves comparing teams, judging individuals, or committing to scope, those options are wrong; use cycle time, throughput trends, or value delivered instead.
Choosing a communication answer that keeps stakeholders at a distance - 'send a weekly status report', 'get sign-off on the requirements', 'ask the sponsor to communicate with users' - instead of options that bring stakeholders into direct, frequent contact with working product.
Status reporting is what most candidates have seen work, and it feels professional and low-risk. Frequent demos and direct stakeholder involvement look informal and slightly risky by comparison, so they get passed over.
What to do instead
For any stakeholder question, ask who needs which information and how fast feedback can be produced. Prefer demos of working software, radiating information (burn charts, Kanban boards, information radiators), and direct conversations; treat reports and sign-offs as fallback options.
Answering conflict scenarios with escalation to the sponsor or manager, avoidance, or reassignment ('the Scrum Master should tell them to stop', 'escalate to HR'), and treating disagreement itself as a defect to be eliminated.
Hierarchy is the default conflict resolution tool in most workplaces, and many candidates read conflict as failure. Agile practice treats healthy disagreement over technical and product choices as a source of better decisions.
What to do instead
Prefer options where the parties are brought together, the disagreement is surfaced and facilitated to a team-owned decision, and escalation appears only after team-level attempts have failed. Conflict over ideas is normal; only personal or destructive conflict needs intervention.
Responding to a change in requirements by re-baselining the schedule, convening a change control board, or extending the iteration to absorb the new work, rather than re-prioritizing the backlog with the product owner for the next iteration.
Candidates trained on predictive exams map 'change' to 'change control'. The agile default - backlog re-ordering and rolling-wave re-planning, with the iteration timebox held fixed - is culturally counterintuitive because it means letting scope move.
What to do instead
Hold two invariants in memory: the timebox is fixed and scope inside it flexes; prioritization is a continuous product owner activity, not a formal approval event. Any option that breaches the timebox or sets scope in stone for the whole project is wrong.
Choosing a remedy that adds capacity, process, or documentation to a slipping iteration - add team members, extend working hours, add a tracking spreadsheet - or shifting to blame the individual who caused the defect.
These are the fastest-sounding fixes and are common in many workplaces. They address the visible symptom without touching the constraint, and blame gives a satisfying sense of explanation.
What to do instead
Look for options that surface and remove the actual impediment: swarm on the bottleneck, limit work in progress, run a root-cause analysis with the team, reduce scope within the iteration, protect the timebox. Adding people to a late iteration and blaming individuals are both wrong on principle.
Choosing a problem-solving or improvement tool by name recognition rather than by matching it to the question asked - offering a fishbone diagram when the question asks how to prioritize, offering a Pareto chart when the question asks for root cause, or offering a burndown chart when the question asks about flow.
Most preparation involves memorizing tool inventories rather than tool triggers, so candidates select by familiarity. The exam almost always states the goal of the analysis explicitly, and the tool must follow from the goal.
What to do instead
For each tool, memorize the question it answers: 5 Whys and fishbone = why did this happen; Pareto = where to focus first; WIP limits and cumulative flow = where work is stuck; burn charts and velocity = how much is left and when; retrospective formats = how we work better.
Treating the retrospective as a reporting ceremony, or selecting options such as 'document lessons learned at project closure' or 'conduct a retrospective at the end of the project' instead of a recurring inspection-and-adaptation cycle with owned actions that are tracked in the next iteration.
Lessons learned at closure is the predictive pattern most candidates know, and retrospectives are often observed in practice as unfocused complaint sessions with no follow-through. The exam tests whether improvement is continuous and actioned.
What to do instead
Prefer options that recur every iteration, produce a small number of specific actions with named owners, and are revisited to confirm whether the change worked. Improvement that is deferred to project end, unattended, or owned by nobody is a wrong answer.