Professional Scrum Competencies
This domain probes the behaviors behind the accountabilities: can you facilitate, coach, teach, mentor, and advise without taking ownership away from the team? Scenario questions reward answers that stay inside the accountability and use empiricism as the test.
The competency areas
- Scrum mastery: explain and apply theory, and diagnose anti-patterns from observed behavior rather than opinion.
- Facilitation: design sessions with purpose, timebox, and a decision rule; hold conflict without resolving it for the group.
- Coaching: ask rather than tell; help the team find its own answer while holding the framework's boundaries firm.
- Teaching: make the why land for this audience, then check understanding.
- Mentoring and consulting: share experience and advise on organizational design, leaving ownership with the team.
- Organizational change: work with stakeholders, metrics, and impediments that sit beyond the team boundary.
What strong answers look like
They name the accountability first ("the Scrum Master would…"), respect self-management by not solving for the team, identify the value or pillar at stake (often courage or transparency), and propose the smallest next step rather than a reorganisation.
Worked example
The team asks the Scrum Master to run the Daily Scrum because they keep overrunning. Competent response: coach the Developers to own the event, offer to facilitate once to demonstrate a technique, then hand it back and review at the Retrospective. Reasoning: the Scrum Master is accountable for the event's effectiveness, not for running it; taking it over creates dependency and violates self-management.
Traps that cost marks
- Hero-Scrum-Master rescues that fix the symptom and remove team ownership.
- "Coaching" answers that are really instructions in disguise.
- Confusing mentoring (sharing experience) with doing the work.
- Treating competencies as a checklist to recite rather than behaviors to demonstrate in a described situation.