Professional Scrum Master I common mistakes
PSM I · Understand the traps and how to avoid them.
Treating the Scrum Master as the person who assigns tasks, runs standups as a status meeting, or owns the Sprint Backlog and tells the Developers what to do.
Candidates carry over command-and-control habits from traditional project management and map 'Scrum Master' onto 'team lead' or 'project manager' from their own workplace experience.
What to do instead
Memorise the Scrum Master's accountabilities verbatim from the Scrum Guide: coaching the team in self-management and cross-functionality, removing impediments, causing the removal of barriers between stakeholders and the team, and ensuring Scrum events are positive, productive, and timeboxed. The Developers own the Sprint Backlog; the Product Owner owns the Product Backlog. Practise classifying each activity as 'Scrum Master does' vs 'Scrum Master causes to happen'.
Assigning the Product Owner sole authority to estimate, or conversely giving the Developers authority to change the Product Backlog order, and mixing up who owns which artifact.
The three artifacts and their owners are superficially similar and candidates conflate 'managing the work' with 'owning the artifact'.
What to do instead
Lock in the ownership table: Product Goal and Product Backlog order belong to the Product Owner; Sprint Goal, Sprint Backlog and estimates belong to the Developers; the Definition of Done is created by the organisation or, if none exists, by the Developers. Drill by writing each artifact and its single accountable owner until recall is automatic.
Describing the Sprint Review as a sign-off, gate, or demo to management, and describing the Sprint Retrospective as a general team meeting where work items are planned.
Candidates map Scrum events onto familiar phase-gate reviews and status meetings rather than reading the stated purpose of each event.
What to do instead
Learn each event's purpose sentence by sentence: the Review inspects the outcome of the Sprint and determines future adaptations, and is a working session with stakeholders, not a gate; the Retrospective plans ways to increase quality and effectiveness. For each event, be able to state its purpose, its timebox, who attends, and its inputs and outputs.
Treating the Daily Scrum as a report to the Scrum Master or Product Owner with the three classic questions, and treating it as mandatory for the whole team to answer to someone.
The three-question format is widely circulated in secondary material and predates the current Scrum Guide, so candidates default to it.
What to do instead
State that the Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog, that it is owned and run by the Developers, and that its structure and technique are up to them. If the Product Owner or Scrum Master attends, they do so as Developers if they are working on Sprint Backlog items, otherwise they participate only if needed.
Describing the Sprint as cancellable by the Scrum Master or the Developers, or describing cancellation as producing a 'failed Sprint' with partial credit.
Candidates reason from general management intuition about stopping work rather than from the single stated authority in the framework.
What to do instead
Memorise that only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete. On cancellation, completed and 'Done' Product Backlog items are reviewed, and anything not Done returns to the Product Backlog for reordering. Rehearse the exact conditions and consequences.
Choosing 'the Scrum Master should tell the Developers to split the work' or 'escalate to the manager' when a question describes a self-management problem, instead of choosing the answer where the team solves it themselves.
Candidates optimise for 'resolving the situation' rather than for 'upholding the framework', and the most decisive-sounding option looks most attractive.
What to do instead
Adopt a decision rule for scenario questions: prefer the answer that keeps accountability with the correct role and lets the team self-manage; reject answers where the Scrum Master or Product Owner makes a decision that belongs to the Developers. When two options both seem reasonable, prefer the one that teaches, coaches, or facilitates over the one that directs.
Reading the Definition of Done as a team-optional checklist that can be relaxed under time pressure, or confusing it with acceptance criteria.
The two concepts are often presented together in study material, and 'Done' feels like a quality nicety rather than a commitment.
What to do instead
Learn that the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product, that it is a commitment for the Increment, and that if it is not met the work cannot be released and does not count toward the Increment. Distinguish it from acceptance criteria, which are item-specific and belong to the Product Backlog item.
Assuming the Product Owner must attend every event and must be present to answer questions, or that the Scrum Team consists of the Developers plus the Scrum Master only.
Candidates absorb organisational habits where the Product Owner is external or part-time, and never internalise the Scrum Team definition.
What to do instead
Memorise that the Scrum Team is one team of ten or fewer people consisting of one Scrum Master, one Product Owner, and Developers, with no sub-teams or hierarchies, and that the whole team is accountable for creating a valuable Increment each Sprint. Learn event attendance precisely: the Sprint Planning, Daily Scrum, Review, and Retrospective are all Scrum Team events, with the Review and Planning also involving stakeholders as needed.
Answering questions about empiricism by quoting 'transparency, inspection, adaptation' without being able to say what each pillar requires in practice, or naming the wrong artifact for a commitment.
The three pillars and three commitments are memorised as lists without being linked to the artifacts, so they collapse under scenario wording.
What to do instead
Build the paired structure explicitly: Product Backlog carries the Product Goal, Sprint Backlog carries the Sprint Goal, Increment carries the Definition of Done. Then practise explaining, for each pillar, one concrete way Scrum enables it: transparency through the artifacts and Definition of Done, inspection through the five events, adaptation through the Sprint and the events' outputs.
Treating Professional Scrum as a set of soft skills and picking 'do whatever the customer asks' or 'follow the process exactly' when a question probes the balance between empiricism and following prescribed events.
Candidates split 'framework compliance' from 'professional judgement' and assume one must win, so they choose an extreme option.
What to do instead
Frame Professional Scrum as applying the framework faithfully and then using empiricism and self-management within it: the events and accountabilities are non-negotiable, but the techniques, formats, and tools are for the team to choose. In scenario questions, prefer the option that preserves the framework while adapting the practice, and reject options that abandon an event or accountability to please a stakeholder.