EXIN Agile Scrum Master common mistakes
EXIN Agile Scrum Master · Understand the traps and how to avoid them.
Answering role questions by describing what a role 'should ideally' do in theory rather than what the EXIN/Scrum Guide assigns as accountability - for example saying the Scrum Master assigns tasks to team members or that the Product Owner chairs the Daily Scrum.
Candidates carry over command-and-control assumptions from traditional project management or from their own workplace, where a 'Scrum Master' is often really a team lead or PM. They answer from experience instead of from the defined accountability.
What to do instead
Before answering any role question, state to yourself the single accountability in one sentence: Product Owner = maximising value of the product and managing the Product Backlog; Scrum Master = establishing Scrum as defined and removing impediments; Developers = creating the Increment. Reject any option that gives a role authority over another role's accountability.
Treating the three Scrum artefacts as documents to be 'completed' or 'signed off', and confusing the Sprint Backlog with a fixed task list that only the Scrum Master may change.
Artefact names sound like familiar project documents (plan, requirements spec, status report), so candidates map old meanings onto them and pick options about baselining or formal approval.
What to do instead
Memorise each artefact together with its commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done. The Sprint Backlog is a living plan owned by the Developers and updated throughout the Sprint; nothing in Scrum requires sign-off of an artefact.
Mixing up the purpose of the five events - e.g. using the Sprint Review to inspect process and the Retrospective to demo the product, or claiming the Daily Scrum is a status meeting for the Scrum Master.
The events look similar on the surface (people meeting regularly) and candidates learn the timeboxes without learning the inspection focus of each. Under time pressure they pick whichever event name appears in the stem.
What to do instead
Anchor each event to what is inspected and adapted: Sprint Planning → why/what/how for the Sprint; Daily Scrum → progress toward the Sprint Goal, for Developers, 15 minutes; Sprint Review → the Increment with stakeholders, adapting the Product Backlog; Retrospective → the team's way of working. If a question mentions stakeholders or the product, it is Review; if it mentions process or collaboration, it is Retrospective.
Choosing the 'helpful' answer for a Scrum Master scenario - taking over a blocked task, deciding priorities for the Product Owner, or telling the Developers how to resolve a disagreement - instead of coaching, facilitating or removing the impediment.
Exam stems describe a problem and the instinct is to select the option that solves it fastest. Servant-leadership answers feel passive, so candidates avoid them even when they are correct.
What to do instead
Apply a rule: the Scrum Master changes the system, not the work. Prefer options that teach, facilitate, shield, or remove an organisational impediment; reject options where the Scrum Master does the Developers' work or overrides the Product Owner. When two options both seem right, pick the one that builds the team's capability rather than the one that fixes today's symptom.
Assuming Scrum scales by adding more people to one team or by lengthening the Sprint, and treating scaling frameworks as interchangeable with Scrum rather than as complementary patterns.
Scaling questions are the least practised area; candidates have vague exposure to SAFe, LeSS or Nexus and answer from buzzwords rather than from the principle that Scrum remains Scrum at scale.
What to do instead
Hold the invariant: scaling keeps the Scrum framework intact and addresses cross-team dependency management, a shared Definition of Done and a single Product Goal. Learn the distinctions at a high level (e.g. Nexus adds an Integration Team and a Nexus Sprint; LeSS applies one Product Owner and one Product Backlog across teams) and prefer answers that reduce dependencies over answers that add coordination meetings.
Reading the stem's situation but ignoring the qualifier - 'FIRST thing the Scrum Master should do', 'BEST', 'NOT', 'MOST likely' - and selecting a correct-sounding action that is not the requested one.
Long scenario stems consume reading time, so candidates skim the final sentence and pattern-match on keywords. EXIN-style items often include several plausible actions where only one fits the qualifier.
What to do instead
Highlight the qualifier before evaluating options, and rank plausible options by sequence or by fit to the qualifier. For 'first', choose diagnosis or facilitation before action; for 'NOT', verify each option against the Scrum Guide rather than picking the first unfamiliar one.
Answering empiricism and Agile-principle questions with generic 'Agile is about flexibility and speed' reasoning, missing the specific concepts the item tests - transparency, inspection, adaptation, the three pillars, or the four values of the Agile Manifesto.
Fundamentals feel easy, so candidates skip revision of definitions and rely on intuition, which cannot distinguish between similar-sounding principles.
What to do instead
Learn the pillars with their enablers (transparency requires a shared Definition of Done; inspection must not disrupt the work; adaptation happens at the earliest opportunity) and be able to state the Agile Manifesto's four value pairs and which side is valued more. When an option mentions speed or efficiency without inspection or transparency, be suspicious.
Confusing the Sprint Goal with the Definition of Done, or the Product Goal with a release plan, and then choosing options about 'finishing all items' as the definition of Sprint success.
All three are short commitment statements, so candidates memorise them as a list of phrases without attaching each to its artefact and its owner.
What to do instead
Build a three-row table - Product Goal (future state of the product, owned by the Product Owner, lives in the Product Backlog), Sprint Goal (single objective for the Sprint, created collaboratively at Planning, lives in the Sprint Backlog), Definition of Done (quality standard for the Increment, owned by the Developers). A Sprint succeeds when the Sprint Goal is met even if some backlog items are not finished.
Treating the Product Owner as a committee, a proxy, or a role that can be split across several people who each own part of the backlog, and accepting stakeholder instructions passed directly to Developers.
Real organisations often have 'business analysts' or 'product managers' acting as intermediaries, and candidates describe their own environment instead of the accountability the exam tests.
What to do instead
Remember the Product Owner is one person who may delegate work but never accountability, must be empowered to make decisions, and is the single point of contact for the Developers on backlog content. Options describing a proxy, a committee, or Developers taking direction from multiple stakeholders are wrong; the fix is to make the Product Owner available and empowered.
Choosing adoption or improvement actions that impose Scrum from the top - mandating ceremonies, installing tools, or rewriting all processes in one reorganisation - rather than incremental, evidence-based change with retrospectives and management support.
Candidates equate 'Agile transformation' with a rollout plan and pick options that sound decisive and structured, which is exactly the mindset the domain tests against.
What to do instead
Prefer options that start small, make the current state visible, and let change emerge from the team's own retrospectives with leadership removing organisational impediments. Reject big-bang mandates, tool-driven adoption and 'train everyone then declare Agile' answers; the correct pattern is continuous improvement, not a one-off project.