ACP-520 common mistakes
ACP-520 · Understand the traps and how to avoid them.
When asked what a Scrum Master or Product Owner should do in a scenario, the candidate picks the answer that describes what a project manager would do (assign work, approve scope, direct the team).
Candidates with traditional PM backgrounds map familiar authority-and-control behaviours onto Agile roles, because those behaviours feel like the 'responsible' answer.
What to do instead
Before answering any role question, restate the role's accountability in one sentence (Scrum Master: process and impediment removal; Product Owner: value and backlog ordering; Developers: how to build). Eliminate any option where the role makes technical or prioritisation decisions outside its accountability.
The candidate treats the Product Owner as the person who writes all user stories and accepts every increment detail, rejecting options where the team collaborates on backlog refinement.
A literal reading of 'single person accountable for the backlog' gets over-extended into 'single person who does all backlog work'.
What to do instead
Separate accountability from activity: the PO is accountable for ordering and clarity, but refinement is a whole-team conversation. Prefer options where the PO collaborates, and distrust options that isolate backlog work in one person.
On estimation questions, the candidate selects an option that converts story points into hours or uses points to compare velocity across teams.
Points feel abstract, so candidates reach for a familiar unit (time) or a familiar comparison (productivity ranking) to make the answer feel rigorous.
What to do instead
Anchor on the definition: points are a relative, team-specific measure of size and uncertainty, never a time unit and never comparable across teams. Any option that divides points by hours, or benchmarks one team's velocity against another's, is wrong.
The candidate chooses 'add more people', 'work overtime', or 'extend the sprint' as the response when a team is falling short of a Sprint Goal.
These are the intuitive levers from schedule-driven delivery, and they appear plausible under exam time pressure.
What to do instead
In Scrum, the sprint length is fixed and scope is the variable negotiated with the Product Owner. Prefer options where the team and PO renegotiate scope or the team raises the impediment; reject options that change the timebox mid-sprint.
The candidate answers a 'what should happen next' question with the immediate tactical action (e.g., 'the Scrum Master reassigns the task') rather than the ceremony or conversation that should occur (e.g., 'raise it in the Daily Scrum' or 'take it to the Retrospective').
Scenario stems reward quick problem-solving, and candidates skip the question of which Agile mechanism owns the problem.
What to do instead
For every scenario, first ask 'which event, artefact, or role owns this?' then pick the option that routes the issue there. Options that solve the problem outside the framework's mechanisms are usually distractors.
The candidate picks the answer that adds a new process, template, or metric to fix a team problem, instead of the answer that inspects and adapts an existing practice.
Adding artefacts feels like decisive action, and Agile improvement questions often have a tempting 'introduce a new dashboard/checklist' option.
What to do instead
Continuous improvement in Agile is empirical: inspect what exists, then adapt. Favour options that use the Retrospective, existing feedback loops, or a small experiment over options that impose new overhead or top-down controls.
The candidate reads velocity, burndown, or a burnup chart as a performance rating of individuals or as a commitment the team must hit.
Metrics are familiar from reporting cultures, so candidates interpret them as targets and accountability tools rather than forecasting aids.
What to do instead
Treat all Agile metrics as planning and reflection tools for the team. Any option that uses velocity to evaluate people, or treats a forecast as a guarantee, is incorrect; prefer options that use trends to inform forecasting and conversation.
The candidate chooses an option where the team silently absorbs a scope change mid-sprint, or where the Product Owner unilaterally swaps work without team input.
Candidates focus on 'the customer is always right' or 'the PO decides' and miss the protected timebox and the team's right to negotiate.
What to do instead
Apply the rule that scope can change only through collaboration between PO and team, and that mid-sprint disruption must be weighed against the Sprint Goal. Prefer options showing negotiation and transparency over unilateral change or silent absorption.
On stakeholder and communication questions, the candidate picks 'send a status report' or 'escalate to management' rather than the option that increases direct transparency and collaboration with stakeholders.
Reporting and escalation are the default communication reflexes, and they look safe under exam conditions.
What to do instead
Agile communication answers favour transparency of the real artefacts (backlog, increment, review) and direct stakeholder contact. Choose options where stakeholders see working product or participate in reviews; treat report-and-escalate options as fallbacks, not first responses.
The candidate answers values-and-principles questions by picking the option that sounds procedurally correct but contradicts a value, such as following a plan over responding to change, or prioritising tools over individuals.
Candidates memorise the four value statements as slogans but do not test each option against them, so they miss the option that quietly violates a value.
What to do instead
For values questions, hold each option against the paired values (individuals over process, working software over documentation, collaboration over contract, responding over planning). Eliminate any option that elevates the right-hand item over the left-hand item, even if the option sounds professional.