From scrum-master
This skill should be used when the user asks about "scrum best practices", "agile principles", "scrum anti-patterns", "improve scrum process", "scrum roles", "scrum artifacts", "scrum events", "product owner responsibilities", "scrum master role", "development team structure", "Product Goal", "Sprint Goal", "Definition of Done", "Product Backlog refinement", "self-managing team", "Increment", "empirical process control", "time-box", or needs guidance on core scrum framework concepts, role definitions, process improvement, or identifying where a team's process diverges from the Scrum Guide.
npx claudepluginhub shinhf/skills-ide-resources --plugin scrum-masterThis skill uses the workspace's default tool permissions.
Provide guidance on the Scrum framework as defined in the Scrum Guide (2020), covering roles, events, artifacts, commitments, and the principles that bind them together. Coach teams on framework questions, diagnose process problems, and identify where a team's implementation diverges from effective scrum practice.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Analyzes BMad project state from catalog CSV, configs, artifacts, and query to recommend next skills or answer questions. Useful for help requests, 'what next', or starting BMad.
Provide guidance on the Scrum framework as defined in the Scrum Guide (2020), covering roles, events, artifacts, commitments, and the principles that bind them together. Coach teams on framework questions, diagnose process problems, and identify where a team's implementation diverges from effective scrum practice.
Scrum rests on three pillars of empirical process control:
Five values support the pillars: Commitment, Courage, Focus, Openness, and Respect. When diagnosing process problems, check whether one or more values have eroded before prescribing mechanical fixes.
A Scrum Team is a small, cross-functional, self-managing unit with no sub-teams or hierarchies. It consists of exactly one Product Owner, one Scrum Master, and Developers. The team is accountable for all product-related activities: stakeholder collaboration, verification, maintenance, operation, experimentation, research, and development.
Recommended team size: 10 or fewer people total. Smaller teams communicate better and are more productive. If the team grows too large, consider reorganizing into multiple cohesive Scrum Teams sharing the same Product Backlog and Product Goal.
Each artifact contains a commitment that provides focus and a measurable target:
| Artifact | Purpose | Commitment |
|---|---|---|
| Product Backlog | Ordered list of everything needed in the product | Product Goal |
| Sprint Backlog | Set of items selected for the Sprint + plan for delivering them | Sprint Goal |
| Increment | Sum of all completed backlog items that meet the Definition of Done | Definition of Done |
The Product Goal describes a future state of the product. It provides long-term direction for the Scrum Team. The Product Backlog emerges from and serves the Product Goal. A Scrum Team must work toward one Product Goal at a time.
The Sprint Goal is a single objective for the Sprint. It provides coherence and focus, enabling the team to make trade-off decisions when scope or approach needs to change mid-Sprint. The Sprint Goal is created during Sprint Planning and added to the Sprint Backlog.
The Definition of Done is a formal description of the state of the Increment when it meets quality measures. It creates transparency and a shared understanding of what "complete" means. The DoD applies uniformly to all backlog items -- no exceptions.
If the organization does not have a standard DoD, the Scrum Team must create one appropriate for the product. The DoD is context-dependent. For example, a software team's DoD might include code review, automated tests passing, and documentation updates, while a hardware team's DoD would look entirely different.
When assessing a team's DoD, verify it:
All Scrum events are time-boxed. Each event is a formal opportunity to inspect and adapt Scrum artifacts.
| Event | Time-box | Purpose |
|---|---|---|
| Sprint | 1-4 weeks (consistent) | Container for all other events; produces a Done Increment |
| Sprint Planning | 8 hours (for 1-month Sprint) | Define Sprint Goal, select items, create plan |
| Daily Scrum | 15 minutes | Inspect progress toward Sprint Goal, adapt Sprint Backlog |
| Sprint Review | 4 hours (for 1-month Sprint) | Inspect Increment, adapt Product Backlog |
| Sprint Retrospective | 3 hours (for 1-month Sprint) | Inspect the Sprint, create improvement plan |
Scale time-boxes proportionally for shorter Sprints.
Refinement is the ongoing activity of adding detail, estimates, and order to Product Backlog items. It is not a formal Scrum event but is essential for effective Sprint Planning.
Key refinement practices:
Items entering Sprint Planning should have clear descriptions, acceptance criteria, and initial size estimates. Apply the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable.
When analyzing a team's scrum implementation, watch for these common anti-patterns:
For the full anti-pattern catalog with detection techniques and remediation strategies, consult references/anti-patterns.md.
When coaching a team on process improvement:
For comprehensive best practices across all scrum dimensions, consult references/best-practices.md.
Open these reference files when deeper detail is needed:
references/anti-patterns.md -- When diagnosing specific process problems: complete anti-pattern catalog with detection signals, impact analysis, and step-by-step remediationreferences/best-practices.md -- When coaching or assessing a team: comprehensive best practices for each scrum role, event, and artifact, including scaling considerations and health metrics