EXIN Agile Scrum Foundation common mistakes
EXIN Agile Scrum Foundation · Understand the traps and how to avoid them.
Treating Scrum as a fixed sequence of phases (requirements, design, build, test) and answering questions as if each Sprint must complete every phase, rather than recognizing each Sprint as a short, repeatable cycle that delivers a potentially shippable Increment.
Candidates with waterfall or PRINCE2-style backgrounds map Scrum events onto phase gates, so they misread questions about Sprint structure and Increment and choose answers describing sequential handoffs.
What to do instead
Practice restating Scrum in one sentence: a cross-functional team produces a Done, usable Increment every Sprint, and all events repeat each Sprint. For any question about structure, ask whether the answer describes a repeating cycle or a one-time phase, and eliminate the phase-based options.
Describing the Product Owner as a committee, a product manager who merely relays requirements, or someone who writes detailed specifications for the team, instead of a single accountable person who maximizes value and owns the Product Backlog.
In many organizations the title exists but the authority does not, so candidates answer from their own workplace rather than the framework definition, and they confuse the role with a traditional business analyst or project manager.
What to do instead
Memorize the accountability in one line: one person, sole owner of the Product Backlog, decides ordering and content, and is the only source of work-item priority. When a question offers a committee or a proxy, eliminate it first, then choose the single accountable person.
Saying the Scrum Master assigns tasks, approves leave or decides priorities, or conversely that the Scrum Master is only a note-taker or meeting organizer.
The role looks like a project manager or a secretary in many workplaces, and candidates split between over-empowering and under-empowering the role rather than describing it as a servant-leader who coaches, removes impediments and teaches Scrum.
What to do instead
Use a two-part test on every Scrum Master answer: does it involve the Scrum Master deciding what the team does (wrong), or helping the team and organization improve how they work (right)? Learn the three service orientations: the team, the Product Owner and the organization.
Confusing the purposes of the Sprint Review and the Sprint Retrospective, for example placing process improvement or team morale in the Review, or placing stakeholder feedback and backlog adaptation in the Retrospective.
Both are end-of-Sprint meetings with the whole team, and the labels sound similar, so candidates rely on the name rather than the outcome each event produces.
What to do instead
Anchor each event to its output: the Review produces an inspected Increment and an adapted Product Backlog; the Retrospective produces improvements to the team's way of working. When an answer mentions stakeholders or product direction it belongs to the Review; when it mentions collaboration, process or working agreements it belongs to the Retrospective.
Treating the Daily Scrum as a status report to the Scrum Master with three fixed questions answered to a manager, and treating the Sprint Planning as a session where the Product Owner hands out tasks.
The three-question format is widely repeated in introductory material, and candidates miss that the event belongs to the Developers, who may structure it however they like as long as it inspects progress toward the Sprint Goal.
What to do instead
Remember that the Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt their plan; the Scrum Master only ensures it happens. If an answer has the Scrum Master collecting updates or assigning work, eliminate it.
Calling the Sprint Backlog a fixed list of tasks that cannot change, or saying the Product Backlog is frozen once a Sprint starts, and therefore rejecting answers in which scope is renegotiated with the Product Owner.
Change is framed as failure in traditional planning, so candidates assume any mid-Sprint adjustment violates Scrum, when in fact the Sprint Goal is fixed while the work to reach it can be adapted.
What to do instead
Separate the stable element from the flexible one: the Sprint Goal is protected, the Sprint Backlog emerges and can change as more is learned, and the Product Backlog is continuously refined. Any answer presenting a frozen artifact or forbidding scope negotiation with the Product Owner is usually wrong.
Treating the Definition of Done as a team preference, an optional checklist, or something the Scrum Master writes, rather than a shared, explicit commitment that makes the Increment transparent and is used to decide whether work is complete.
Candidates confuse it with acceptance criteria, which are per-item, and with a quality checklist owned by a QA group, so they miss that the Definition of Done applies to every item and is owned by the team, often with organizational standards.
What to do instead
Learn the distinction: acceptance criteria are specific to one backlog item; the Definition of Done applies to all items and to the Increment. If an item does not meet the Definition of Done, it is not done and returns to the Product Backlog; answers that make the Definition of Done optional or externally owned are wrong.
Using velocity as a target to be increased, comparing velocities across teams, or converting story points directly into hours, instead of treating estimates as relative, team-specific forecasts.
Managers ask for predictability in hours, so candidates import earned-value thinking and select answers that reward higher velocity or cross-team comparison, which contradicts the purpose of relative estimation.
What to do instead
State the rule: story points measure relative size and uncertainty, velocity is a planning aid specific to one team, and points are never converted to hours. Any answer that sets velocity as a performance goal, compares teams, or multiplies points by an hourly rate should be eliminated.
Choosing 'the Product Owner prioritizes by business value alone' or 'the team pulls the highest-value item first' and ignoring the roles of risk, dependencies, learning and refinement in ordering the Product Backlog.
Value-based prioritization is repeated so often that it becomes the only criterion candidates consider, and they forget that ordering is a Product Owner decision informed by many factors, including technical input from the Developers.
What to do instead
Remember that the Product Owner orders the backlog to maximize value, using input from the team on risk, effort and dependencies. Answers that reduce ordering to a single mechanical rule, or that let the Developers decide priority, are distractors.
Answering improvement questions with generic advice such as 'communicate better' or 'add more documentation', or blaming individuals, instead of describing empirical, team-driven improvement through transparency, inspection and adaptation, with impediments made visible.
Improvement questions feel like soft-skills questions, so candidates pick the most agreeable-sounding option rather than the one grounded in Scrum's empirical process and the Scrum Master's role in removing impediments.
What to do instead
For any improvement question, prefer answers that make work and problems visible, shorten feedback loops, and let the team own the change. Eliminate answers that add control, add reporting, single out a person, or solve the problem for the team instead of with it.