Expert Scrum Master

An autonomous agent that facilitates Scrum practices — running ceremonies, removing impediments, coaching teams on agile principles, measuring team health, and driving continuous improvement through retrospectives and metrics.

When to Use This Agent

Choose Expert Scrum Master when:

• You need to establish or improve Scrum practices for a development team
• Ceremonies (standups, sprint planning, retros) need structure and facilitation
• You want to measure team velocity, predictability, and health
• Impediments are blocking the team and need systematic resolution

Consider alternatives when:

• You need project-level management across multiple teams (use a PM agent)
• You need product strategy and prioritization (use a product champion agent)
• You want Kanban rather than Scrum (adapt the approach or use a Kanban agent)

Quick Start

Copy
# .claude/agents/scrum-master.yml
name: expert-scrum-master
description: Facilitate Scrum practices and team improvement
agent_prompt: |
  You are a Scrum Master. Help teams practice effective Scrum:

  1. Facilitate sprint ceremonies with clear agendas
  2. Track and remove impediments
  3. Coach the team on Scrum values and principles
  4. Measure velocity, predictability, and team health
  5. Drive continuous improvement through retrospectives
  6. Shield the team from external interruptions

  Scrum principles:
  - The team commits to the sprint, the Scrum Master commits to the team
  - Retrospective actions must be implemented, not just discussed
  - Velocity is a planning tool, not a performance metric
  - The Daily Standup is for the team, not for management

Core Concepts

Sprint Ceremony Framework

Ceremony	Duration	Purpose	Participants
Sprint Planning	2-4 hours	Define sprint goal and select stories	Team + PO
Daily Standup	15 minutes	Sync, identify blockers	Team
Sprint Review	1-2 hours	Demo completed work, get feedback	Team + stakeholders
Sprint Retrospective	1-1.5 hours	Improve process and teamwork	Team
Backlog Refinement	1-2 hours	Clarify and estimate upcoming stories	Team + PO

Sprint Planning Agenda

Sprint Planning (2 hours for 2-week sprint)

Part 1: What (45 min)
  - PO presents sprint goal and priority stories
  - Team asks clarifying questions
  - Team and PO agree on sprint goal

Part 2: How (45 min)
  - Team breaks stories into tasks
  - Team estimates effort for tasks
  - Team commits to sprint backlog based on velocity

Part 3: Commitment (30 min)
  - Review capacity (vacations, holidays, meetings)
  - Adjust sprint backlog based on capacity
  - Team formally commits to sprint goal
  - SM confirms: "Can we achieve this sprint goal?"

Team Health Metrics

Velocity Trend:
  Sprint 1: 34 pts | Sprint 2: 38 pts | Sprint 3: 35 pts | Sprint 4: 37 pts
  Average: 36 pts | Variance: ±3 pts (8%) ← Good predictability

Sprint Predictability:
  Committed: 36 pts | Delivered: 34 pts | Ratio: 94% ← Healthy

Team Health Radar:
  Collaboration:    ████████░░  8/10
  Technical Debt:   ██████░░░░  6/10 ← Needs attention
  Morale:           █████████░  9/10
  Process:          ███████░░░  7/10
  Stakeholder Trust:████████░░  8/10

Configuration

Option	Type	Default	Description
sprintLength	number	2	Sprint duration in weeks
teamSize	number	7	Number of team members
ceremonies	string[]	["planning", "standup", "review", "retro"]	Active ceremonies
velocityWindow	number	4	Sprints used for velocity calculation
impedimentSLA	number	48	Hours to resolve impediments
healthCheckFrequency	string	"monthly"	Team health assessment frequency

Best Practices

1. Keep Daily Standups to 15 minutes — no exceptions — Each person answers three questions: What did I do? What will I do? What is blocking me? Detailed discussions happen after the standup in separate conversations. A 30-minute standup signals that the meeting has become a status report for management rather than a team sync.

2. Track sprint predictability, not just velocity — Velocity measures output; predictability measures reliability. A team that commits to 40 points and delivers 40 is more valuable than a team that commits to 40 and delivers 60 (inconsistent) or 30 (under-delivering). Calculate the ratio of delivered to committed across sprints.

3. Implement at least one retro action item every sprint — A retrospective without follow-through is worse than no retrospective because it teaches the team that feedback does not lead to change. Select 1-2 action items, assign owners, and review completion at the next retro. Small, consistent improvements compound over time.

4. Protect sprint commitments from mid-sprint changes — When stakeholders add urgent work mid-sprint, something must be removed. Make the trade-off visible: "We can add this, but we'll need to drop Story X. Which is more important?" This forces explicit prioritization rather than implicit overload.

5. Use velocity for planning, never for performance evaluation — The moment velocity becomes a performance metric, teams inflate estimates to show higher velocity. Velocity should help predict how much work can fit in a sprint, not measure individual or team productivity. If management asks for velocity numbers, explain why this is counterproductive.

Common Issues

Standups become status reports to the manager — Team members address the Scrum Master or manager instead of each other, turning the standup into a reporting meeting. The SM should stand to the side, not at the front. Direct team members to talk to each other: "Tell the team what you're working on" rather than "Tell me what you're working on."

Sprint velocity fluctuates wildly — Velocity swings from 20 to 50 between sprints, making planning impossible. Common causes: inconsistent story point estimation, unplanned work entering the sprint, and team composition changes. Focus on estimation consistency (use reference stories for calibration) and track unplanned work separately to identify and reduce interruptions.

Retrospective actions are never completed — The team generates great ideas in retros but never implements them. Limit retro action items to 1-2 per sprint (not 5-10), assign a specific owner to each, and add them as tasks in the next sprint backlog with the same visibility as feature work. Review previous action items at the start of every retro.