Scrum Master Accountabilities

Core Identity: Servant-Leader

The Scrum Master serves the team and organization — they do not command, assign, or control. They create conditions for others to succeed. Every accountability flows from this stance.

Serving the Developers

  • Coaching the Developers in self-management and cross-functionality

  • Helping them focus on creating high-value Increments that meet the Definition of Done

  • Removing impediments to their progress (but not solving every problem for them — they help the team solve it)

  • Ensuring Scrum events happen and are positive, productive, and timeboxed

Serving the Product Owner

  • Helping find techniques for effective Product Goal definition and Product Backlog management

  • Helping the team understand the need for clear, concise Product Backlog items

  • Facilitating stakeholder collaboration as requested or needed

Serving the Organization

  • Leading, training, and coaching the organization in Scrum adoption

  • Planning and advising Scrum implementations

  • Helping employees and stakeholders understand and enact an empirical approach

  • Removing barriers between stakeholders and the Scrum Team

The Exam Tip in Practice

If an answer says the Scrum Master does any of these, it's almost certainly wrong:

  • Assigns tasks to Developers

  • Approves the Sprint Backlog

  • Manages the budget or schedule

  • Decides what goes into the Product Backlog

  • Resolves conflicts by making the final call

  • Reports team performance to management

  • Tells the Product Owner what to prioritize

The Scrum Master facilitates, coaches, and removes obstacles — they never direct the work or own decisions that belong to the Developers or Product Owner.

Quick Memory Anchor

Think of the Scrum Master as a coach on the sideline, not a player and not the team owner. They help everyone play better — but they don't touch the ball.

Emperical Approach . 3 pillars

Empiricism means decisions are based on observation, experience, and evidence — not assumption or prediction. It's the philosophical foundation the entire Scrum framework is built on.

Transparency — The process and work must be visible to those doing the work and those receiving it. No hidden backlogs, no private definitions of done. Everyone sees reality as it is.

Inspection — Scrum artifacts and progress are frequently examined to detect undesirable variances. This happens at every Scrum event.

Adaptation — If inspection reveals something is off, an adjustment must be made as soon as possible to minimize further deviation.

The three pillars are interdependent — you can't adapt what you can't inspect, and you can't inspect what isn't transparent.