What the Scrum Master campaign trains
The Scrum Master campaign starts from a single trap most new Scrum Masters fall into: the moment you start telling the team what to do, you have stopped being a Scrum Master and started being a project manager. The early lessons define the role around servant leadership and facilitation basics, then use a dedicated game to practice spotting an impediment versus something that merely looks like one, a slow decision is not automatically a blocker, and a disagreement is not automatically dysfunction.
From there the module works through the events the Scrum Master is accountable for making effective: running the Daily Scrum so it stays an inspection of progress toward the Sprint Goal rather than a status report to a manager, keeping retrospective formats fresh enough that they do not go stale after the fifth iteration, facilitating Sprint Planning without dictating the plan, and facilitating refinement so the team, not the Scrum Master, shapes the backlog conversation. A checkpoint on spotting impediments and a game on coaching rather than commanding reinforce the same idea from two directions: your job is to remove obstacles and ask better questions, not to solve every problem yourself.
The middle of the campaign covers protecting the team without becoming a wall, a distinction that separates effective Scrum Masters from ones who make themselves the bottleneck for every external conversation, teaching Scrum to a brand-new team, and a set of coaching questions specifically designed to unlock a team that already knows the answer but has not said it out loud. A harder-mode checkpoint on impediments raises the difficulty once the basics are solid.
The campaign closes with two topics that separate a working Scrum Master from a title holder: which metrics a Scrum Master should actively avoid promoting, because velocity comparisons and individual output tracking corrode the psychological safety the role exists to protect, and a clear-eyed look at what 'scaling Scrum' actually requires versus the shortcuts organizations reach for first. A final lesson on Scrum Master anti-patterns ties the whole campaign together by naming the failure modes directly: the Scrum Master as secretary, as manager, as meeting-scheduler, and as the only person allowed to talk to stakeholders.
Mistakes teams make with this material
Jumping in to fix every blocker yourself instead of coaching the team to remove it. This builds dependency on you and prevents the team from becoming self-managing, which is the actual goal of the accountability.
Going person by person reporting what was done yesterday to the Scrum Master, instead of the team inspecting progress toward the Sprint Goal together. That single habit turns a self-organizing event into a reporting line.
Shielding the team so completely that no one else develops the confidence to talk to a stakeholder directly. Protecting the team is not the same as making yourself indispensable to every conversation.
Publishing team velocity as a target or comparing it across teams. Velocity is a forecasting input for the team itself, not a productivity metric, and using it as one reliably produces inflated estimates and damaged trust.
Questions people ask
What is the difference between a Scrum Master and a project manager?
A project manager typically plans, assigns, and tracks work toward a deadline. A Scrum Master does not assign work; they facilitate the team's own events, coach self-management, and remove impediments the team cannot clear itself. The authority runs through the team, not through the Scrum Master.
How do I know if something is a real impediment?
A real impediment is blocking progress toward the Sprint Goal and is outside the team's ability to resolve on its own, a broken CI pipeline, a stakeholder who has gone silent, an approval stuck in another department. A disagreement the team is actively working through, or a task that is simply hard, usually is not.
Which metrics should a Scrum Master avoid?
Anything that ranks individuals, story points completed per person, hours logged, or lines of code, and anything that turns team velocity into a cross-team comparison or an external target. These metrics get gamed almost immediately and damage the transparency the team needs to function.