PSL N41 common mistakes
PSL N41 · Understand the traps and how to avoid them.
Treating Scrum as a fixed prescriptive process and answering that the Scrum Master enforces rules, assigns tasks, or ensures the team follows steps exactly, rather than describing Scrum as an empirical, lightweight framework built on transparency, inspection, and adaptation.
Candidates memorize event names and roles but skip the theory chapter, so they default to a command-and-control mental model drawn from prior project-management experience.
What to do instead
For every scenario question, first ask which empirical pillar or Scrum value is at stake, then pick the answer that increases transparency or enables self-management rather than one that adds control.
Selecting an answer where the Scrum Master directs the team's work, assigns backlog items, or makes technical decisions for developers.
The role title 'Master' and prior managerial habits suggest authority, and candidates confuse accountability for the process with authority over the work.
What to do instead
Anchor on the definition: the Scrum Master is accountable for the team's effectiveness and for establishing Scrum as defined in the Guide; the Developers own the how, the Product Owner owns the what and why.
Describing the Scrum Team as having a separate 'development team' sub-unit, a 'Scrum Master as team lead', or a project manager outside the team, and treating the three accountabilities as separate teams.
Legacy terminology from older Scrum versions and organizational charts persists in candidates' memory, and the Guide's 'one team, three accountabilities, no sub-teams' framing is easy to miss.
What to do instead
Memorize that a Scrum Team is ten or fewer people, cross-functional and self-managing, with no sub-teams or hierarchies; test any answer for hidden sub-teams or external managers and reject it.
Answering that the Daily Scrum is a status report to the Scrum Master or stakeholders, that it must be 15 minutes of three questions, or that it cannot be changed in format.
Common corporate practice and outdated training material frame the Daily Scrum as a status meeting with a rigid script.
What to do instead
Recall it is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the plan; the structure is chosen by the Developers and others may attend only if it helps.
Saying the Sprint Review is a sign-off, demo, or gate where stakeholders approve the Increment, or that the Sprint Retrospective is optional when the team is busy.
Stage-gate governance habits and time pressure make candidates soften events or reframe them as approvals; the purpose statements get blurred.
What to do instead
Learn each event's purpose verbatim: Review inspects the outcome and adapts the Product Backlog; Retrospective plans ways to increase quality and effectiveness; no event may be skipped, only shortened within its timebox.
Confusing the Product Goal, Sprint Goal, Definition of Done, and Product Backlog with their artifacts, or treating the Definition of Done as a checklist owned by the Scrum Master.
The commitments were added to the Guide relatively recently, so candidates who learned older versions miss the artifact-commitment pairing entirely.
What to do instead
Build a one-line mapping and rehearse it: Product Backlog to Product Goal, Sprint Backlog to Sprint Goal, Increment to Definition of Done; the Definition of Done is a commitment the whole Scrum Team creates and the organization can mandate as a minimum.
Stating that the Sprint Backlog cannot change during the Sprint or that scope is frozen once the Sprint begins.
Candidates conflate 'no changes that endanger the Sprint Goal' with a rigid scope lock, a common misreading of Sprint scope protection.
What to do instead
Remember the Sprint Goal is fixed while the Sprint Backlog emerges; scope may be clarified and renegotiated with the Product Owner as more is learned, as long as the Sprint Goal is not endangered.
When asked how to facilitate a difficult event, choosing to cancel the event, extend it beyond its timebox, or let the Scrum Master decide the outcome instead of proposing facilitation techniques that protect the timebox and the event's purpose.
Candidates answer from a problem-solving instinct ('fix the conflict for them') instead of from the facilitator stance of designing the container and letting the team own the content.
What to do instead
Practice answering with facilitation moves: set the purpose and timebox, use techniques like dot voting or fist-of-five, and intervene on process while leaving content decisions to the team.
Answering coaching scenarios with advice-giving, telling the team what to do, or escalating to management first, rather than asking questions, reflecting, and helping the team find its own solution.
Candidates confuse coaching with mentoring or consulting and reach for the fastest-sounding fix, which is usually direct instruction.
What to do instead
Use the test 'does this answer build the team's capability or create dependence on the Scrum Master?'; prefer open questions, observation, and feedback over directives, and reserve escalation for genuine impediments the team cannot remove.
Treating servant leadership as doing the team's work, shielding the team from all discomfort, or removing every obstacle personally, instead of teaching the team to remove its own impediments and serving the team's growth.
'Servant' is read as 'accommodating', so candidates pick answers where the Scrum Master absorbs all difficulty and protects the team from stakeholders.
What to do instead
Frame servant leadership as removing organizational impediments the team cannot, coaching self-management, and connecting the team to stakeholders; when the team can solve it, the Scrum Master's job is to help them see that, not to solve it for them.