Menü
Scrum and agile facilitation expertise for engineering teams. Use when planning sprints, facilitating retrospectives, removing blockers, tracking velocity and burndown, improving team processes, or coaching teams on agile principles and practices.
AI agent architecture and development patterns including tool use, memory systems, planning loops, and multi-agent orchestration. Use when building AI agents, designing tool interfaces, or implementing agent evaluation.
Prompt engineering principles and techniques for LLM applications including system prompts, chain-of-thought, few-shot learning, and prompt evaluation. Use when designing prompts, optimizing LLM outputs, or building prompt pipelines.
API design principles for REST, GraphQL, and gRPC including versioning, pagination, error handling, and documentation. Use when designing new APIs, reviewing API contracts, or migrating between API styles.
System architecture design including requirements analysis, trade-off evaluation, ADRs, and system decomposition. Use when designing new systems, evaluating architectures, or documenting design decisions.
Business analysis expertise for translating business needs into technical requirements. Use when eliciting requirements from stakeholders, modeling business processes, writing functional specifications, performing gap analysis, defining data dictionaries, or creating acceptance test scenarios from business rules.
Product management analysis for engineering-informed decision framing. Use when a task needs product framing, feature prioritization based on user impact and engineering reality, scope control to prevent complexity creep, or structured now/next/later sequencing with explicit tradeoffs.
| name | scrum-master |
| description | Scrum and agile facilitation expertise for engineering teams. Use when planning sprints, facilitating retrospectives, removing blockers, tracking velocity and burndown, improving team processes, or coaching teams on agile principles and practices. |
| summary_l0 | Facilitate Scrum ceremonies, sprint planning, retrospectives, and agile coaching |
| overview_l1 | This skill provides Scrum and agile facilitation expertise for engineering teams. Use it when planning sprints, facilitating retrospectives, removing blockers, tracking velocity and burndown, improving team processes, or coaching teams on agile principles and practices. Key capabilities include sprint planning facilitation, backlog refinement guidance, daily standup optimization, retrospective design and facilitation, velocity and burndown tracking, blocker identification and resolution, agile metric interpretation, and team coaching on Scrum, Kanban, and scaled agile frameworks. The expected output is structured agile ceremony outputs (sprint plans, retrospective action items, velocity reports) and process improvement recommendations. Trigger phrases: sprint planning, retrospective, scrum master, agile coaching, velocity, burndown, blockers, scrum ceremony, backlog refinement, sprint review. |
Structured scrum and agile facilitation frameworks for engineering teams. This skill provides sprint planning tools, retrospective formats, metrics dashboards, and coaching patterns that connect agile principles to daily engineering execution.
Use this skill for:
Trigger phrases: "sprint planning", "daily standup", "retrospective", "retro", "velocity", "burndown", "cycle time", "WIP limit", "impediment", "blocker", "scrum", "agile", "sprint goal", "definition of done", "definition of ready", "backlog refinement", "sprint review", "demo", "team health", "continuous improvement"
Provides a seven-step scrum facilitation workflow that covers the complete sprint lifecycle, from planning through delivery, with metrics and coaching patterns for continuous improvement.
Sprint planning translates backlog items into a realistic commitment organized around a clear sprint goal. Never plan at 100% utilization; leave room for unplanned work, meetings, and support duties.
Capacity Calculation Template:
SPRINT CAPACITY: Sprint [Number]
─────────────────────────────────
Sprint duration: [N] days | Team size: [N] members
Team Member | Available Days | Capacity Factor | Effective Days
─────────────|────────────────|─────────────────|───────────────
[Name] | 10 | 0.7 | 7.0
[Name] | 8 (PTO 2d) | 0.7 | 5.6
─────────────|────────────────|─────────────────|───────────────
Team total effective days: [sum]
Unplanned buffer (20%): [sum * 0.2]
Committable capacity: [sum * 0.8]
Capacity factor 0.7 accounts for meetings, code review, and context switching.
Adjust per role: seniors 0.6 (more review); juniors 0.75.
Story Point Estimation Techniques:
| Technique | Best For | How It Works |
|---|---|---|
| Planning Poker | Teams of 3-9, well-defined stories | Fibonacci cards (1,2,3,5,8,13,21). Reveal simultaneously. Discuss outliers. Re-vote. |
| T-Shirt Sizing | Large backlogs, rough sizing | XS/S/M/L/XL mapped to point ranges (XS=1, S=2, M=3, L=5, XL=8+). |
| Affinity Mapping | New teams, bulk estimation | Sort stories into relative groups on a wall. Assign points to groups. |
| Reference Stories | Teams with history | Pick 3-5 completed stories as calibration anchors. Compare new stories against them. |
Rules: Estimate complexity and risk, not hours. If a story exceeds 13 points, split it. The team estimates, not the scrum master.
Sprint Goal Definition:
SPRINT GOAL: Sprint [Number]
────────────────────────────
Goal: [One sentence: the outcome, not a feature list]
Success test: [How will we know the goal is met at sprint review?]
Key stories: [3-5 stories that directly serve this goal]
Anti-goal: [What this sprint is NOT trying to achieve]
Good: "Users can complete onboarding end-to-end without manual intervention". Bad: "Complete stories ABC-123, ABC-124, ABC-125" (task list, not a goal).
Backlog Refinement Checklist (run mid-sprint for the upcoming sprint):
Definition of Ready (entry gate for sprint planning):
The daily standup is a coordination event where the team synchronizes on progress, surfaces blockers, and adjusts the plan. It is not a status report to the scrum master.
Standup Format Options:
| Format | Structure | Best For |
|---|---|---|
| Classic Three Questions | Did / Will do / Blockers | Small co-located teams (3-5) |
| Walk the Board | Right-to-left across the board, discuss each in-progress item | Teams focused on finishing over starting |
| Round Robin with Focus | One priority + one risk per person | Larger teams (6-9) |
| Exception-Based | Speak only if blocked, need help, or changed plans | Mature self-organizing teams |
Walk the Board Protocol: Start at "In Review" (can we get these to Done?), move to "In Progress" (anything stuck > 2 days?), then "To Do" (who pulls next? WIP limits respected?). Park detailed discussions for after standup. 15 minutes max.
Async Standup Template (for distributed teams):
ASYNC STANDUP: [Name] - [Date]
───────────────────────────────
DONE: [Completed items with ticket refs]
WORKING ON: [Current focus with ticket ref]
BLOCKED BY: [Blocker + who can unblock] or "No blockers"
NEEDS SYNC: [Topic requiring a live conversation] or "None"
Post by a consistent deadline daily. Scrum master reviews within 1 hour and flags blockers.
Kanban Board Design:
Column | WIP Limit | Entry Criteria | Exit Criteria
──────────────|───────────|────────────────────────────|─────────────────────
Backlog | None | Meets Definition of Ready | Pulled into sprint
To Do | None | In current sprint backlog | Developer picks it up
In Progress | 2/dev | Developer assigned | Code complete, tests pass
In Review | 3 total | PR opened, CI green | Approved by reviewer
Done | None | Merged and deployed/staged | N/A
WIP Limits: Team WIP for "In Progress" = team size * 1.5 (rounded down). When limits are hit: stop starting, help finish, investigate why items are stuck. Signs limits are too high: items sit "In Progress" 3+ days, people juggle 3+ items. Signs too low: developers idle waiting for reviews.
Blocker Identification Checklist (check daily):
Flow Metrics (track weekly):
| Metric | Definition | Target |
|---|---|---|
| Cycle Time | "In Progress" to "Done" | < 3 days |
| Lead Time | Backlog entry to "Done" | < 10 days |
| Throughput | Items completed per week | [team baseline] |
| Blocker Count | Active blockers | 0 |
The sprint review demonstrates working software and collects stakeholder feedback. It is not a slideshow.
Demo Preparation Checklist (complete 1 day before review):
Sprint Review Agenda (60 min for a 2-week sprint):
Stakeholder Feedback Log:
ID | Feedback | Source | Type | Priority | Action
────|─────────────────|─────────────|─────────|──────────|───────────
F-1 | [text] | [Name/Role] | Feature | [H/M/L] | Add to backlog
F-2 | [text] | [Name/Role] | Bug | [H/M/L] | Fix next sprint
Types: Feature, Bug, Enhancement, Question, Praise, Concern. Priority: H = next sprint, M = 2-3 sprints, L = backlog.
Release Readiness Assessment:
The retrospective is the team's most important continuous improvement tool. Vary the format to prevent staleness and always end with concrete action items.
Psychological Safety Ground Rules (read aloud at the start of every retro):
Check-in question (rotate): "In one word, how did this sprint feel?" or "On a scale of 1-5, how confident are you that we can improve next sprint?"
Format 1: Start / Stop / Continue (45 min, best for new teams)
Brainstorm (5 min): sticky notes for Start, Stop, Continue. Group themes (10 min). Dot vote with 3 votes each (5 min). Discuss top 3 themes with root cause analysis (20 min). Select 1-3 actions with owners (5 min).
Format 2: 4Ls - Liked / Learned / Lacked / Longed For (45 min, balances positives with gaps)
Same process as Start/Stop/Continue. "Learned" and "Longed For" reveal training needs and tooling gaps that other formats miss.
Format 3: Sailboat (60 min, visual metaphor for abstract concepts)
Draw: Island (destination/goal), Wind/Sails (what propelled us), Anchor (what slowed us), Rocks (risks ahead), Sun (recognition). Silent brainstorm (7 min), cluster (10 min), discuss anchors and rocks (25 min), actions (8 min).
Format 4: Timeline (60 min, best after significant events or incidents)
Build a chronological timeline of sprint events with color coding (green/red/yellow). Walk through events, identify patterns and turning points. Use "5 Whys" on the most impactful negative pattern. Actions target root causes.
Format 5: Mad / Sad / Glad (45 min, when morale needs attention)
Three columns for emotions. Validate feelings before problem-solving. If "Mad" items target individuals, redirect to the process. If the board is mostly "Mad" and "Sad", team morale needs attention beyond the retro.
Action Item Tracking:
RETRO ACTION TRACKER
─────────────────────
Sprint | Action | Owner | Due Date | Status
───────|───────────────────────────────|─────────|────────────|──────────
S-14 | Set up automated deploy | [Alice] | 2026-04-01 | Done
S-15 | Reduce PR review to <24h | [Team] | 2026-04-15 | Not Started
Rules: Review last sprint's actions at the START of every retro. Max 3 new actions. Actions must be specific and measurable. If not done after 2 sprints, re-commit or drop honestly.
Metrics are tools for the team's self-improvement, not management surveillance. Use them to spot trends, not to judge individuals.
Velocity Tracking: Track story points completed per sprint. Use the rolling average over the last 3 sprints for planning (not the peak). Never compare velocity between teams.
Burndown vs Burnup: Burndown tracks remaining work (flat sections = stuck items; staircase = stories too large). Burnup tracks completed work plus scope changes (makes mid-sprint scope additions visible). Use burnup when scope creep is recurring.
Cycle Time vs Lead Time: Lead Time = backlog entry to Done. Cycle Time = "In Progress" to Done. A large gap means items sit in the backlog too long. Track weekly averages over 4-6 sprints.
Throughput: Items completed per week. Often more stable than velocity because it is unaffected by estimation inconsistencies. Use for forecasting: "At 5.5 items/week, 20 items takes approximately 3.6 weeks".
Escaped Defects: Escape Rate = Production Defects / (Sprint Defects + Production Defects) * 100. Target < 15%. Track which defect categories escape most to focus testing improvements.
Metric Interpretation Guide:
| Metric | Healthy | Warning |
|---|---|---|
| Velocity | Stable within +/- 15% over 4+ sprints | Swings of 30%+ or declining |
| Cycle Time | Consistent or decreasing | Increasing over 3+ sprints |
| Throughput | Stable or increasing | Decreasing with same team size |
| Escaped Defects | < 15% escape rate | > 25% or rising trend |
| Sprint Goal | Met 80%+ of sprints | Missed 3+ consecutive |
| Carry-over | < 10% of committed points | > 25% carried over regularly |
Anti-Patterns in Metrics:
| Anti-Pattern | Harm | Alternative |
|---|---|---|
| Comparing velocity across teams | Teams estimate differently; comparison is meaningless | Compare each team to its own trend |
| Velocity as a KPI | Teams inflate estimates to look productive | Use velocity for planning only |
| Demanding velocity increase | Encourages cutting corners | Focus on removing impediments |
| Tracking individual velocity | Discourages collaboration | Track team-level metrics only |
| Ignoring metrics entirely | Problems invisible until crisis | Review 2-3 metrics weekly |
| Cherry-picking good sprints | Hides systemic issues | Use rolling averages over 4+ sprints |
The scrum master's core responsibility is removing obstacles that prevent the team from delivering. Track impediments systematically and escalate promptly.
Impediment Log Template:
IMPEDIMENT LOG
───────────────
ID | Raised | Description | Impact | Owner | Status
───────|────────────|──────────────────────────|───────────|─────────|───────────
IMP-01 | 2026-03-15 | CI pipeline takes 45 min | SLOWING | [SM] | In Progress
IMP-02 | 2026-03-16 | No staging env access | BLOCKING | [DevOps]| Escalated
Impact levels: BLOCKING (resolve in hours), SLOWING (resolve in 2 days), ANNOYING (resolve within sprint).
Escalation Paths:
| Level | Who | Resolve In | Triggers |
|---|---|---|---|
| 1: Team | Scrum Master | 4 hours | Tooling, access, unclear requirements |
| 2: Cross-team | SM + Eng Manager | 2 days | Dependencies, resource conflicts, process disagreements |
| 3: Management | Eng Manager + Director | 1 week | Budget, policy blocks, staffing gaps |
| 4: Executive | VP/CTO | 2 weeks | Strategic misalignment, cross-department conflicts |
Rule: Never escalate without documenting the problem, impact, options considered, and a recommended path forward.
Dependency Tracker:
ID | Our Team Needs | From Team | Needed By | Status | Risk
───────|───────────────────────|──────────────|────────────|──────────|─────────
DEP-01 | Auth API v2 endpoint | Platform | Sprint 16 | On Track | Low
DEP-02 | Updated design system | Design | Sprint 15 | At Risk | High
Review weekly. For "At Risk" or "Blocked" dependencies, maintain a mitigation plan. Communicate missed deadlines immediately.
Cross-Team Coordination: Weekly 30-min sync with scrum masters from dependent teams. Agenda: dependency status review (10 min), upcoming needs (10 min), blocker resolution (10 min).
Risk Register:
ID | Risk | Likelihood | Impact | Score | Mitigation | Owner
───────|─────────────────────────|────────────|────────|───────|─────────────────────────|──────
RSK-01 | Key developer leaves | Low | High | 6 | Cross-train on crit path| [SM]
RSK-02 | Scope creep | High | Medium | 9 | Enforce change process | [PO]
Scoring: Likelihood (1-3) x Impact (1-3). Review weekly; daily when score >= 6.
Decision Log:
DECISION LOG
─────────────
ID | Date | Decision | Context | Decided By | Reversible
───────|────────────|─────────────────────────────|────────────────────────────|────────────|───────────
DEC-01 | 2026-03-15 | Use PostgreSQL over MongoDB | Need strong consistency | Tech Lead | No
DEC-02 | 2026-03-18 | Adopt trunk-based dev | Reduce merge conflicts | Team | Yes
Record every decision affecting architecture, process, or scope. Include context so future team members understand the reasoning. Mark reversibility so the team knows which decisions can be revisited cheaply.
A high-performing team is not just fast; it is healthy, engaged, and continuously improving.
Team Health Check (quarterly, based on the Spotify model):
Rate GREEN/YELLOW/RED with trend arrows (UP/FLAT/DOWN) for: Delivering Value, Speed, Code Quality, Fun, Learning, Mission Clarity, Teamwork, Psychological Safety, Management Support, Sustainable Pace. Aggregate anonymously. Discuss RED items and declining trends. Select 1-2 dimensions to improve next quarter with specific actions.
Agile Maturity Assessment:
| Level | Name | Characteristics |
|---|---|---|
| 1 | Adopting | Follows Scrum events, roles defined, basic metrics tracked |
| 2 | Practicing | Self-organizes within sprint, retro actions completed, DoD enforced, realistic planning |
| 3 | Optimizing | Proactive impediment removal, metrics drive decisions, CI/CD and TDD embedded |
| 4 | Mastering | Adapts processes to context, coaches other teams, high predictability |
Rate each area 1-4. Focus growth plans on the lowest-scoring areas.
Coaching Patterns:
| Pattern | When to Use | How to Apply |
|---|---|---|
| Ask, Don't Tell | Team asks SM to decide | "What options do you see?" |
| Silent Observer | Team looks to SM for permission | Attend standup but do not speak unless asked |
| Pair Facilitation | Developing future scrum masters | Co-facilitate a retro, then debrief |
| Teaching Moment | Team makes a process mistake | Wait for retro; ask "what did we learn?" |
| Mirror | Unaware dysfunctional pattern | "I noticed standups run 25 min. What causes that?" |
| Shield | External pressure threatens sprint | Absorb management requests; protect team focus |
| Connector | Team lacks skills or information | Connect with experts, training, or outside resources |
Scaling Frameworks Overview:
| Framework | Teams | Key Concepts | Best For |
|---|---|---|---|
| SAFe | 5-125+ | Agile Release Trains, Program Increments | Large enterprises with compliance needs |
| LeSS | 2-8 | One Product Backlog, one PO, Sprint Review Bazaar | Single-product companies |
| Nexus | 3-9 | Nexus Integration Team, Cross-Team Refinement | Scrum-mature teams needing lightweight coordination |
| Scrum@Scale | 2-1000+ | Scrum of Scrums, MetaScrum | Scaling organic scrum practices |
Start with the simplest framework that fits your context. No framework replaces the need for strong scrum masters on individual teams.
Definition of Done Evolution:
| Stage | When | Criteria Added |
|---|---|---|
| Foundation | New teams | Code compiles, unit tests pass, peer-reviewed, merged, acceptance criteria verified |
| Quality | After 3-5 sprints | Integration tests pass, coverage meets standard, no new static analysis warnings, tested on staging |
| Production-Ready | After 8-10 sprints | Feature flagged, monitoring configured, docs updated, performance tested, security reviewed |
| Excellence | Mature teams | Accessibility audited, runbook updated, release notes written, knowledge sharing scheduled |
Review the DoD every quarter. Add criteria when the team consistently meets current items. Never remove criteria to make a story "Done" that would otherwise fail; adjust in the retrospective for future sprints.
| Situation | Recommended Tool | Step |
|---|---|---|
| "How much can we commit?" | Capacity Calculation | Step 1 |
| "How big is this story?" | Estimation Techniques | Step 1 |
| "Is this story ready?" | Definition of Ready | Step 1 |
| "What should standup focus on?" | Walk the Board | Step 2 |
| "How do we coordinate across time zones?" | Async Standup | Step 2 |
| "Are we finishing or just starting?" | WIP Limits + Flow Metrics | Step 2 |
| "What do we demo?" | Demo Preparation Checklist | Step 3 |
| "Can we release this?" | Release Readiness Assessment | Step 3 |
| "How do we improve?" | Retrospective Formats | Step 4 |
| "Are we getting faster or slower?" | Velocity + Cycle Time | Step 5 |
| "What is blocking us?" | Impediment Log + Escalation | Step 6 |
| "How healthy is our team?" | Team Health Check | Step 7 |
| "When is a story truly done?" | Definition of Done | Step 7 |
| Rationalization | Reality |
|---|---|
| "Plan the sprint at full capacity, the team can handle it" | Planning at 100% utilization ignores meetings, review, and support, so the first interruption blows the commitment. The 0.7 capacity factor and 20% buffer are what keep carry-over under 10%. |
| "The sprint goal is just the list of committed stories" | A story list is not an outcome the team can rally around or measure at review. "Users complete onboarding without manual intervention" tells the team what to cut when time runs short; a ticket list does not. |
| "Velocity is up this sprint, so the team is doing better" | Velocity is an estimation artifact, not a productivity score. Treating it as a KPI makes the team inflate estimates; use the rolling 3-sprint average for planning only and compare a team only to its own trend. |
| "Skip reviewing last retro's actions, we have new issues to discuss" | Unreviewed action items quietly die, and the team learns retros do not change anything. Reviewing prior actions at the START of every retro is what makes the next round of commitments credible. |
| "A blocker can wait until the next standup to escalate" | A BLOCKING impediment left for 24 hours stalls the whole story and often a dependency. The escalation table sets hours-not-days resolution targets precisely so blockers do not accumulate. |
Version: 1.0.0 Last Updated: March 2026
This skill is optimized for an iterative approach: