Professional Scrum Master I (PSM I) common mistakes
PSM I · Understand the traps and how to avoid them.
When a scenario says the team learns mid-Sprint that it cannot meet the Sprint Goal, the candidate answers 'finish the Sprint exactly as planned and review it at the Sprint Review' instead of adapting.
Prior waterfall/contract-style experience frames the Sprint as a fixed-scope commitment with a change freeze until the next formal meeting.
What to do instead
Memorise the empiricism loop: transparency surfaces the new information, the team inspects, and it adapts the Sprint Backlog immediately. The Sprint Goal is fixed for the Sprint, but scope may be renegotiated with the Product Owner as more is learned; cancelling is a last resort and only when the Sprint Goal becomes obsolete.
On questions about a surprise, a missed expectation, or a stakeholder complaint, the candidate picks 'adapt' or 'inspect' as the answer without first identifying what was not visible, e.g. answering 'the team should inspect more often' when nobody had raised the issue at all.
The three pillars are memorised as vocabulary rather than as a sequence, so any scenario containing the word 'problem' triggers the same keyword.
What to do instead
Diagnose the missing pillar first: if the relevant information never surfaced to the right people, the failure is transparency; if it surfaced and was ignored, inspection; if it was understood and nothing changed, adaptation. Most 'we didn't know until the end' scenarios are transparency failures, not inspection-frequency failures.
Answers accountability questions by assigning commitments to the wrong role, e.g. 'the Product Owner is accountable for the Sprint Goal', 'the Scrum Master owns the Product Backlog', or 'the Developers own the Product Goal'.
The three artifacts, their three commitments and their accountabilities are learned as two separate lists and get cross-wired under time pressure.
What to do instead
Memorise one chain and reconstruct the rest from it: Product Backlog -> Product Goal -> Product Owner; Sprint Backlog -> Sprint Goal -> Developers; Increment -> Definition of Done -> Developers. Say the chain out loud before answering any 'who owns X' question.
Treats the Scrum Master as a team lead, status collector or people manager, choosing answers like 'the Scrum Master assigns the work items' or 'the Scrum Master decides when the team is done'.
The job title is imported from previous organisations where 'Scrum Master' was a line-management or project-coordination role.
What to do instead
Anchor on the two services the Scrum Master actually provides (to the Scrum Team and to the organisation) and on the phrase 'true leader who serves'. The Scrum Master coaches, facilitates, teaches and removes impediments, but the answers never have the Scrum Master deciding content or assigning work.
Describes the Sprint Review as a demo or an approval gate ('the stakeholders sign off the Increment') and describes the Sprint Retrospective as something to skip when the team is busy or the Sprint went well.
Stage-gate and project-sign-off habits, plus a belief that ceremonies are optional overhead rather than required elements of the framework.
What to do instead
Learn each event as purpose first, mechanics second. Sprint Review: inspect the outcome, determine future adaptations, collaborate with stakeholders - it is a working session, not a presentation or a gate. All five events are required; the Retrospective is where inspection of the team's own process happens and is the last thing to drop, never the first.
States the Daily Scrum must use the three questions, must be held standing up, and that the Scrum Master must run it, then rules out answers where the Developers change the format or where the Scrum Master is absent.
Many teams inherited a rigid Daily Scrum script, and the exam questions using 'the team wants to change the format' look like a violation of the rules.
What to do instead
The Daily Scrum is for the Developers, is timeboxed to 15 minutes, and its structure and technique are chosen by the Developers. The three questions are one optional technique. The Scrum Master ensures the event happens and stays within the timebox, but does not have to run it and can be absent.
Answers that the Definition of Done is whatever the Scrum Team invents, and rejects answers where an organisational standard constrains the team's definition.
The phrase 'the Scrum Team creates the Definition of Done' is remembered, but the qualifier about organisational standards is not.
What to do instead
If an organisational Definition of Done exists, all teams must follow it as a minimum; a team may add stricter criteria but may not weaken it. Only when no organisational standard exists does the Scrum Team create one. Work that does not meet the Definition of Done is not an Increment and returns to the Product Backlog.
Says the team must release at the end of every Sprint, or that there is exactly one Increment per Sprint, and eliminates answers that describe several Increments being created within a single Sprint.
Release and Increment are treated as synonyms, and 'potentially releasable' is misread as 'must be released'.
What to do instead
Separate the two ideas: an Increment is created whenever a Sprint Backlog item meets the Definition of Done, so several can exist within one Sprint. Releasing is a separate business decision owned by the Product Owner and is not mandated by Scrum. An Increment is a concrete stepping stone toward the Product Goal.
Accepts extensions or early termination too freely, e.g. 'the Sprint can be extended by a few days to finish testing' or 'the Scrum Master or the stakeholders can cancel the Sprint'.
Intuition says a fixed-length Sprint should flex when work is nearly done, and cancellation sounds like a management call.
What to do instead
Two hard rules to recall verbatim: the Sprint is a fixed-length event of one month or less whose duration never changes, and only the Product Owner may cancel a Sprint. Cancellation happens only when the Sprint Goal becomes obsolete, and completed items are reviewed for release.
Assumes Scrum prescribes co-location, a particular tool or board, story points, or adoption of a named scaling framework, and picks answers that mandate those as part of 'doing Scrum correctly'.
Candidates generalise from their own organisation's implementation and from Agile-branded practices that are not part of the Scrum framework.
What to do instead
Treat Scrum as a lightweight framework that defines only the accountabilities, events, artifacts and rules - not techniques, tooling, metrics, or scaling methods. If an answer adds a mandated practice that the framework never specifies, it is almost always wrong.