SM common mistakes
SM · Understand the traps and how to avoid them.
Treating the Scrum Master as the team's administrator or project manager, choosing the answer where the SM assigns tasks, resolves conflicts by decree, or reports status upward as the primary duty.
Candidates carry over habits from traditional project management roles and equate 'leader' with 'person who directs work and owns outcomes'.
What to do instead
For every SM-behaviour option, ask 'does this build the team's own capability to self-manage?' Answers that make decisions for the team, or that position the SM as the team's boss or status reporter, are wrong; the SM teaches, coaches, facilitates, and removes impediments.
Accepting an answer that has the Scrum Master or Product Owner cancel a Sprint, or that lets the team extend a Sprint to finish work.
Cancellation feels like a management decision, and extending feels pragmatic when work is nearly done, so candidates pick the 'practical' option.
What to do instead
Memorise that only the Product Owner can cancel a Sprint, and only when the Sprint Goal becomes obsolete; a Sprint's length is fixed once it starts and cannot be extended. Any option that shortens, lengthens, or cancels without the PO is wrong.
Confusing the Sprint Review with a status meeting or a demo, and choosing answers where the Review's purpose is to report progress to stakeholders or get sign-off.
The word 'review' suggests approval, and many workplaces run it as a slide deck for management.
What to do instead
Anchor on the purpose: the Sprint Review inspects the outcome and determines future adaptations; it is a working session with stakeholders to collaborate on what to do next, not a gate or a report. Options that emphasise approval, sign-off, or presenting to an audience are wrong.
Treating the Daily Scrum as a status report to the Scrum Master, or requiring each person to answer the three questions to a facilitator.
Status-reporting habits can make a planning event for Developers look like a report to a manager.
What to do instead
The Daily Scrum is for the Developers to inspect progress toward the Sprint Goal and adapt the plan; it is owned by the Developers, not the SM. Choose answers where Developers organise the event and the focus is the Sprint Goal, not individual reporting.
Assuming the Product Backlog must be fully refined or fully estimated before a Sprint can start, or that the Sprint Backlog is fixed and cannot change.
Plan-driven instincts suggest that work must be fully specified up front, and 'commitment' is misread as a frozen scope.
What to do instead
The Product Backlog is emergent and never complete; the Sprint Backlog is a living plan updated as more is learned. Reject options requiring exhaustive up-front detail or forbidding change within a Sprint, while remembering the Sprint Goal is the fixed commitment.
Mixing up the three artifact commitments, e.g. pairing the Product Backlog with the Sprint Goal or the Increment with the Definition of Done's predecessor concepts.
The commitments were added later and are easy to memorise as a vague list without mapping each to its artifact.
What to do instead
Lock the pairs: Product Backlog -> Product Goal; Sprint Backlog -> Sprint Goal; Increment -> Definition of Done. When a question names an artifact, immediately recall its single commitment before reading the options.
Choosing answers where the Scrum Master enforces Scrum mechanically on the team or mandates process compliance, rather than helping the team understand and own Scrum.
'Servant leader' and 'process guardian' get blended, and enforcement sounds like a clear, decisive action.
What to do instead
Scrum is founded on empiricism and self-management; the SM's job is to teach, facilitate, and coach so the team adopts Scrum by understanding, not by policing. Options that impose rules, punish non-compliance, or mandate ceremonies are wrong.
Confusing servant leadership with passivity, picking answers where the SM waits to be asked, avoids difficult conversations, or lets the team fail without intervening.
The word 'servant' can be mistaken for waiting passively instead of actively helping the team.
What to do instead
Servant leadership is active: removing impediments, coaching through conflict, protecting the team's focus, and provoking change. Choose options where the SM takes initiative to enable the team's success without taking ownership away from the team.
Assuming the Scrum Team is a fixed set of sub-teams with a separate 'dev team' inside it, or that roles are optional/specialised silos.
Older Scrum terminology and real-world org charts suggest a nested dev team and distinct role handoffs.
What to do instead
A Scrum Team is one self-managing, cross-functional unit of ten or fewer people with three accountabilities: Product Owner, Scrum Master, Developers. Reject options describing sub-teams, role handoffs, or a separate 'development team' inside the Scrum Team.
Picking 'add more process' or 'escalate to management' as the fix for team dysfunction, rather than choosing coaching, facilitation, or transparency-based empiricism.
Escalation and added controls feel like decisive, safe answers under exam pressure.
What to do instead
Prefer the option that increases transparency, inspection, and adaptation within the team, and that builds the team's ability to solve the problem itself. Escalation is a last resort for organisational impediments the team cannot influence, not the default response to team issues.