A Scrum Master who runs every ceremony on time can still leave a team stuck. The real test is whether the team can expose delivery risks early, resolve blockers without dependency theatre, and improve its way of working from one sprint to the next. That is the standard to use when deciding how to coach scrum masters: not activity, but observable improvement in team capability and delivery outcomes.
This is a practical guide for Agile Coaches, delivery leaders and experienced Scrum Masters responsible for raising the operating standard across multiple teams. It focuses on coaching in real organisations, where dependencies, inherited processes, uneven leadership support and delivery pressure are normal conditions.
Start with the Scrum Master’s operating context
Do not begin with a generic development plan. Begin by understanding the system in which the Scrum Master works. A capable Scrum Master in a stable, product-led team needs different support from one working across shared services, quarterly commitments and competing management demands.
Observe at least one full sprint cycle before drawing conclusions. Attend planning, the Daily Scrum, refinement, review and retrospective. Review the board, the sprint goal, carry-over work, impediment records and recent retrospectives. Then speak separately with the Product Owner, engineering lead and several team members. You are looking for patterns, not isolated complaints.
Ask practical questions. Does the team have a usable sprint goal? Is work entering the sprint ready enough to start? Are ageing items visible? Does the Product Owner make timely decisions? Does the team regularly release usable increments? Does the Scrum Master intervene in every problem, or help the team own its decisions?
This baseline prevents a common coaching error: treating a symptom as a personal capability gap. Poor planning may reflect weak facilitation, but it may also result from uncontrolled incoming work, unclear product priorities or a technical dependency outside the team’s control. Coach the Scrum Master to distinguish what they can influence directly from what needs escalation or wider system change.
How to coach Scrum Masters through evidence
Coaching becomes vague when feedback is based on personality or preference. Replace statements such as “be more proactive” with evidence, impact and a specific next experiment.
For example: “In the last three planning sessions, the team committed before agreeing a sprint goal. During the sprint, two priority changes displaced planned work. Next sprint, facilitate goal-setting before selecting items, then test whether unplanned work reduces.” This gives the Scrum Master a clear behaviour to practise and a measure that matters.
Use a small scorecard rather than an elaborate maturity model. Track only signals that help a coaching conversation:
- Sprint goal clarity and achievement
- Work carried over between sprints
- Blocked-work age and resolution ownership
- Predictability of throughput over several sprints
- Quality signals, including defects found after release
- Retrospective actions completed and their measurable effect
Qualitative evidence matters too. Listen for who speaks, who decides and who stays silent. If the Scrum Master answers every question in refinement, the team may be dependent on them. If a retrospective produces the same complaints every fortnight, the issue may be lack of follow-through rather than poor facilitation. If a Product Owner routinely bypasses the backlog, a team-level intervention will not be enough.
Coach the stance, not just the ceremonies
Many Scrum Masters know the Scrum events. Fewer can shift deliberately between facilitator, coach, teacher, mentor and impediment remover. Developing that judgement is central to enterprise-level success.
In a new or struggling team, a Scrum Master may need to be more directive for a short period. They might establish working agreements, make workflow policies visible and teach the purpose of each event. In a mature team, the same behaviour becomes counterproductive. The Scrum Master should step back, let the team facilitate parts of its own process and challenge it to solve recurring problems independently.
Use live debriefs after key events. Ask the Scrum Master what they intended, what they observed, where they intervened and what they would change. Avoid taking over the next session yourself unless there is a genuine delivery risk. Modelling is useful; rescuing is not.
A useful coaching prompt is: “What capability should the team have gained by the end of this quarter?” The answer should be concrete. Perhaps the team can run effective refinement without the Scrum Master driving every discussion. Perhaps it can manage blocked work through explicit escalation rules. Perhaps it can use review feedback to reshape the backlog rather than treating the Sprint Review as a demonstration meeting.
Build a disciplined coaching cadence
A monthly catch-up is rarely enough. Scrum Master capability develops through short feedback loops, just as delivery capability does. Establish a cadence with a clear purpose for each interaction.
A weekly 30-minute coaching session should focus on one live challenge, not a status report. Review evidence, identify the underlying constraint, agree one or two experiments and define what will show progress. Keep a simple coaching log containing the situation, hypothesis, agreed action, owner and review date.
Use fortnightly observation selectively. Do not attend every event indefinitely. Choose the moments that reveal the current development area: planning for commitment discipline, Daily Scrum for flow management, review for stakeholder collaboration, or retrospective for continuous improvement. Give feedback promptly while the detail is still fresh.
Every six to eight weeks, conduct a broader operating review with the Scrum Master and relevant delivery partners. Compare the team’s baseline with current evidence. Discuss where the Scrum Master is adding leverage and where organisational constraints are blocking progress. This is the point to raise systemic issues with leaders, supported by clear facts rather than Agile rhetoric.
Develop the difficult capabilities first
The highest-value coaching work is often uncomfortable because it concerns influence, conflict and boundaries. A Scrum Master who can facilitate a retrospective but cannot challenge a senior stakeholder’s disruptive request will struggle to protect focus. A Scrum Master who reports impediments but never drives a resolution path becomes an administrator of delay.
Coach these capabilities in real situations. Rehearse a conversation with a Product Owner who keeps changing priorities mid-sprint. Help the Scrum Master frame an escalation around impact, options and a decision needed. Practise asking an engineering manager to address persistent quality debt without turning the conversation into blame.
The goal is not for Scrum Masters to become process police. It is to help them create conditions where transparency leads to action. They should be able to make work visible, facilitate a productive challenge, agree an operating decision and verify that it has been followed.
This also means coaching boundaries. Scrum Masters should not own the product backlog, assign tasks, become the team’s project secretary or absorb every coordination duty. Those habits can look helpful under pressure, but they weaken accountability and make the delivery system dependent on one person.
Standardise the essentials, preserve judgement
When coaching several Scrum Masters, establish a shared minimum standard. Teams should have a clear definition of ready where appropriate, visible workflow policies, consistent impediment handling, meaningful sprint goals and usable retrospective actions. Common artefacts reduce administrative friction and make cross-team risks easier to see.
Do not standardise every facilitation technique or force identical cadences where context differs. A platform team, a customer-facing product team and a team supporting urgent operational work will not use Scrum in precisely the same way. Standardise the outcomes and controls; allow thoughtful variation in the method.
A practical community of practice can accelerate this work when it is based on real cases. Ask Scrum Masters to bring one delivery problem, the evidence they gathered and the experiment they ran. This creates peer learning without turning the session into a presentation forum. Battle-tested templates for observation notes, coaching plans and impediment escalation can make that discipline easier to sustain.
Know when the problem is not the Scrum Master
Coaching cannot compensate indefinitely for organisational contradictions. If leaders demand fixed scope while changing priorities weekly, if teams lack authority to address quality issues, or if every dependency requires several approvals, the Scrum Master is working against the system.
Your role is to make this visible without using the Scrum Master as a shield. Help them document the pattern, quantify the impact and present viable options. For example, repeated carry-over might justify smaller batch sizes, a dependency service-level agreement or a change to planning horizons. The appropriate intervention depends on the constraint, not on a textbook interpretation of Scrum.
The strongest coaching relationship makes itself less necessary over time. A well-coached Scrum Master sees the system clearly, chooses the right stance, uses evidence to improve it and develops the team’s own ability to do the same. That is when better delivery stops being a coaching initiative and becomes normal operating practice.