{
  "id": "page:library-scrum",
  "_kind": "Page",
  "_file": "wiki/library/scrum.md",
  "_cluster": "wiki",
  "attributes": {
    "nodeKind": "Page",
    "title": "Scrum (Library)",
    "displayName": "Scrum (Library)",
    "slug": "library/scrum",
    "articlePath": "wiki/library/scrum.md",
    "article": "\n# Scrum\n\n**Creators**: Ken Schwaber and Jeff Sutherland\n**Year**: 1995 (dominant since 2001)\n**Category**: Agile Sprint-Based Framework\n**Priority**: Medium\n\n## Overview\n\nScrum is a lightweight agile framework for developing, delivering, and sustaining complex products through iterative progress via sprints. It is the most widely adopted agile framework worldwide, used by organizations from startups to Fortune 500 companies.\n\nScrum emphasizes empirical process control (empiricism) with three pillars:\n- **Transparency**: Significant aspects of the process must be visible\n- **Inspection**: Regular inspection of artifacts and progress toward goals\n- **Adaptation**: Adjustment of process when inspection reveals unacceptable deviation\n\nScrum is particularly well-suited for:\n- **Complex adaptive problems** where requirements emerge and evolve\n- **Product development** requiring frequent feedback and adaptation\n- **Cross-functional teams** (3-9 people) with all necessary skills\n- **Organizations seeking agility** and rapid response to change\n- **Projects with high uncertainty** where waterfall approaches fail\n\n## Key Principles\n\n### Three Roles\n\n1. **Product Owner**\n   - Maximizes value of product and work of Development Team\n   - Manages and prioritizes Product Backlog\n   - Ensures backlog is visible, transparent, and understood\n   - Makes final decisions on priorities\n   - Single person (not committee)\n\n2. **Scrum Master**\n   - Servant-leader for Scrum Team\n   - Ensures Scrum is understood and enacted\n   - Facilitates Scrum events as needed\n   - Removes impediments blocking the team\n   - Shields team from external interference\n   - Coaches team on self-organization\n\n3. **Development Team**\n   - Professionals who deliver potentially releasable Increment\n   - Self-organizing (chooses how to do work)\n   - Cross-functional (all skills needed to create Increment)\n   - 3-9 members optimal (small enough to be nimble, large enough to complete work)\n   - No sub-teams or titles (everyone is \"Developer\")\n   - Collectively accountable\n\n### Five Events\n\nAll events are time-boxed to minimize waste and maximize value:\n\n1. **Sprint** (1-4 weeks, commonly 2 weeks)\n   - Container for all other events\n   - Fixed length throughout development\n   - No changes that endanger Sprint Goal\n   - New Sprint starts immediately after previous\n\n2. **Sprint Planning** (max 8 hours for 1-month sprint)\n   - What can be done this Sprint?\n   - How will the chosen work get done?\n   - Creates Sprint Goal and Sprint Backlog\n   - Whole team collaborates\n\n3. **Daily Scrum** (15 minutes)\n   - Daily inspection and adaptation\n   - Three questions: What did I do? What will I do? Any impediments?\n   - Synchronize activities and plan next 24 hours\n   - Development Team only (others may observe)\n\n4. **Sprint Review** (max 4 hours for 1-month sprint)\n   - Inspect Increment with stakeholders\n   - Demo completed work\n   - Gather feedback\n   - Adapt Product Backlog\n   - Collaborative working session\n\n5. **Sprint Retrospective** (max 3 hours for 1-month sprint)\n   - Inspect how Sprint went regarding people, relationships, process, tools\n   - What went well? What to improve?\n   - Create improvement plan\n   - Occurs after Sprint Review, before next Sprint Planning\n\n### Three Artifacts\n\n1. **Product Backlog**\n   - Ordered list of everything needed in product\n   - Single source of requirements\n   - Never complete (evolves as product and environment evolve)\n   - Product Owner responsible for content, availability, ordering\n\n2. **Sprint Backlog**\n   - Product Backlog Items selected for Sprint\n   - Plus plan for delivering them\n   - Forecast by Development Team\n   - Real-time picture of work planned for Sprint\n\n3. **Increment**\n   - Sum of all Product Backlog Items completed during Sprint\n   - Must meet Definition of Done\n   - Must be in usable condition (potentially shippable)\n   - Step toward vision or goal\n\n## Usage\n\n### Basic Usage\n\n```javascript\nimport { babysit } from '@a5c-ai/babysitter-sdk';\n\nconst result = await babysit({\n  process: 'methodologies/scrum',\n  inputs: {\n    projectName: 'Mobile Banking App',\n    productVision: 'Secure, user-friendly mobile banking with account management, transfers, and bill pay',\n    sprintDuration: 2,      // 2-week sprints\n    sprintCount: 6,         // Plan 6 sprints (3 months)\n    teamSize: 7\n  }\n});\n```\n\n### With Pre-Defined Product Backlog\n\n```javascript\nconst result = await babysit({\n  process: 'methodologies/scrum',\n  inputs: {\n    projectName: 'E-Commerce Platform',\n    productVision: 'Online retail platform with shopping cart, payment, and order tracking',\n    sprintDuration: 2,\n    sprintCount: 8,\n    teamSize: 9,\n    backlogItems: [\n      {\n        id: 'PBI-001',\n        title: 'User Registration',\n        userStory: 'As a customer, I want to register an account, so that I can save my preferences',\n        acceptanceCriteria: [\n          'Email validation',\n          'Password strength requirements',\n          'Email confirmation sent'\n        ],\n        storyPoints: 5,\n        priority: 'must-have',\n        type: 'feature'\n      },\n      {\n        id: 'PBI-002',\n        title: 'Shopping Cart',\n        userStory: 'As a customer, I want to add items to cart, so that I can purchase multiple items',\n        acceptanceCriteria: [\n          'Add/remove items',\n          'Update quantities',\n          'Show total price'\n        ],\n        storyPoints: 8,\n        priority: 'must-have',\n        type: 'feature'\n      }\n    ]\n  }\n});\n```\n\n### With Custom Definition of Done\n\n```javascript\nconst result = await babysit({\n  process: 'methodologies/scrum',\n  inputs: {\n    projectName: 'Healthcare Portal',\n    productVision: 'Patient portal for appointments, records, and communication',\n    sprintDuration: 3,\n    sprintCount: 4,\n    teamSize: 6,\n    definitionOfDone: {\n      criteria: [\n        {\n          category: 'Code Quality',\n          requirements: [\n            'Code reviewed by at least 2 team members',\n            'Unit test coverage >= 80%',\n            'No critical security vulnerabilities',\n            'Meets HIPAA compliance requirements'\n          ]\n        },\n        {\n          category: 'Testing',\n          requirements: [\n            'All acceptance criteria met',\n            'Integration tests pass',\n            'UAT completed by Product Owner',\n            'Accessibility standards met (WCAG 2.1 AA)'\n          ]\n        },\n        {\n          category: 'Documentation',\n          requirements: [\n            'API documentation updated',\n            'User documentation updated',\n            'Release notes drafted'\n          ]\n        }\n      ]\n    },\n    productOwner: 'Jane Smith',\n    scrumMaster: 'John Doe'\n  }\n});\n```\n\n## Input Schema\n\n```typescript\ninterface ScrumInputs {\n  // Required\n  projectName: string;              // Project/product name\n  productVision: string;            // High-level product vision and goals\n\n  // Optional\n  sprintDuration?: number;          // Sprint length in weeks (default: 2, recommended: 1-4)\n  sprintCount?: number;             // Number of sprints to plan (default: 6)\n  teamSize?: number;                // Development Team size (default: 7, recommended: 3-9)\n  backlogItems?: Array<PBI>;        // Pre-defined Product Backlog Items (optional)\n  productOwner?: string;            // Product Owner name (default: 'Product Owner')\n  scrumMaster?: string;             // Scrum Master name (default: 'Scrum Master')\n  definitionOfDone?: Object;        // Custom Definition of Done criteria (optional)\n}\n\ninterface PBI {\n  id: string;\n  title: string;\n  userStory: string;                // \"As a [role], I want [feature], so that [benefit]\"\n  acceptanceCriteria: string[];\n  storyPoints: number;              // Fibonacci: 1, 2, 3, 5, 8, 13, 21\n  priority: 'must-have' | 'should-have' | 'could-have' | 'won\\'t-have';\n  type: 'feature' | 'technical' | 'bug' | 'research';\n  businessValue?: number;\n  dependencies?: string[];\n}\n```\n\n## Output Schema\n\n```typescript\ninterface ScrumOutput {\n  success: boolean;\n  projectName: string;\n  productVision: string;\n\n  // Product Backlog\n  productBacklog: {\n    initial: {\n      items: PBI[];\n      totalItems: number;\n      totalStoryPoints: number;\n      epics: Array<{ name: string; pbiIds: string[] }>;\n    };\n    final: PBI[];  // Remaining after sprints\n  };\n\n  // Definition of Done\n  definitionOfDone: {\n    criteria: Array<{\n      category: string;\n      requirements: string[];\n    }>;\n    checklist: string[];\n    rationale: string;\n  };\n\n  // Sprints\n  sprints: Array<{\n    sprintNumber: number;\n    sprintGoal: string;\n    startDate: string;\n    endDate: string;\n    duration: number;\n    sprintBacklog: PBI[];\n    tasks: Task[];\n    totalStoryPoints: number;\n    dailyScrums: DailyScrum[];\n    burndown: BurndownData;\n    review: SprintReview;\n    retrospective: Retrospective;\n  }>;\n\n  // Velocity Metrics\n  velocityMetrics: {\n    velocities: number[];\n    averageVelocity: number;\n    totalCompletedStoryPoints: number;\n    totalCompletedItems: number;\n    velocityTrend: number;\n    improving: boolean;\n    standardDeviation: number;\n  };\n\n  // Release Burndown\n  releaseBurndown: {\n    burndownData: Array<{\n      sprint: number;\n      remaining: number;\n      completed: number;\n    }>;\n    initialStoryPoints: number;\n    remainingStoryPoints: number;\n    completedStoryPoints: number;\n    completionPercentage: number;\n  };\n\n  // All Retrospectives\n  retrospectives: Retrospective[];\n\n  // Team Info\n  roles: {\n    productOwner: string;\n    scrumMaster: string;\n    teamSize: number;\n  };\n\n  // Summary Metrics\n  metrics: {\n    sprintCount: number;\n    sprintDuration: number;\n    averageVelocity: number;\n    totalStoryPoints: number;\n    totalBacklogItems: number;\n    completedBacklogItems: number;\n    completionRate: number;\n  };\n}\n```\n\n## Process Workflow\n\n### Phase 1: Initial Setup\n\n**Establish Definition of Done**\n- Define what \"Done\" means for this team\n- Include code quality, testing, documentation, deployment criteria\n- Ensure it creates potentially releasable Increment\n- Get team agreement\n\n**Create Product Backlog**\n- Product Owner identifies all needed work\n- Write as user stories with acceptance criteria\n- Estimate using story points (Fibonacci sequence)\n- Order by business value\n- Refine top items for Sprint Planning\n\n### Phase 2: Sprint Cycles\n\nEach sprint follows the same rhythm:\n\n**1. Backlog Refinement** (Ongoing, ~10% of sprint capacity)\n- Add detail to upcoming items\n- Break down large items\n- Update estimates\n- Re-order based on new information\n- Ensure top items are \"Ready\"\n\n**2. Sprint Planning** (Beginning of sprint)\n- Part 1: What can be done? (Define Sprint Goal, select PBIs)\n- Part 2: How will it be done? (Break into tasks, create plan)\n- Result: Sprint Goal + Sprint Backlog\n\n**3. Daily Scrum** (Every day, 15 minutes)\n- What did I do yesterday?\n- What will I do today?\n- Any impediments?\n- Update task board and burndown\n\n**4. Development Work** (Throughout sprint)\n- Self-organizing team does the work\n- Collaborate to meet Sprint Goal\n- Adapt plan as needed\n- Maintain focus (no scope changes)\n\n**5. Sprint Review** (End of sprint)\n- Demo completed work to stakeholders\n- Inspect Increment against Definition of Done\n- Gather feedback\n- Update Product Backlog\n- Calculate velocity\n\n**6. Sprint Retrospective** (After Review)\n- What went well?\n- What could be improved?\n- What will we commit to improve?\n- Create action items for next sprint\n\n### Phase 3: Final Summary\n\n**Velocity Analysis**\n- Average velocity over all sprints\n- Velocity trend (improving or declining)\n- Predictability (standard deviation)\n\n**Release Burndown**\n- Progress across all sprints\n- Remaining Product Backlog\n- Completion percentage\n\n## Examples\n\nSee the `examples/` directory for:\n- `simple.json` - Basic 2-week sprint setup\n- `e-commerce.json` - E-commerce platform development\n- `mobile-app.json` - Mobile application with 3-week sprints\n- `enterprise.json` - Large enterprise project with 1-week sprints\n- `startup.json` - Startup MVP with flexible scope\n\n## Best Practices\n\n### 1. Keep Sprints Short and Consistent\n\n**Recommended**: 2-week sprints\n- Short enough for rapid feedback\n- Long enough to deliver meaningful Increments\n- Consistent length aids predictability\n\n**Avoid**: Changing sprint length mid-project\n\n### 2. Definition of Done is Critical\n\nA clear Definition of Done ensures:\n- Quality is built-in\n- Increment is potentially shippable\n- Technical debt doesn't accumulate\n- Transparency for stakeholders\n\n**Must include**: Code quality, testing, documentation standards\n\n### 3. Product Backlog is Never Complete\n\nThe Product Backlog evolves continuously:\n- New items discovered during Sprints\n- Priorities change based on feedback\n- Items refined just-in-time\n- Lower priority items less detailed\n\n**Anti-pattern**: Trying to define all requirements upfront\n\n### 4. Sprint Goal Provides Focus\n\nEvery Sprint should have a clear Sprint Goal:\n- Describes why the Sprint is valuable\n- Provides coherence and focus\n- Guides trade-off decisions\n- Rallies team around common objective\n\n**Example**: \"Enable users to complete checkout process\"\n\n### 5. Daily Scrum is for Development Team\n\nThe Daily Scrum is not a status report to management:\n- Self-organizing team synchronizes\n- 15 minutes maximum\n- Same time and place daily\n- Scrum Master ensures it happens, doesn't lead it\n\n**Anti-pattern**: Management-driven status meetings\n\n### 6. Sprint Review is Working Session\n\nSprint Review is collaborative, not just a demo:\n- Stakeholders provide feedback\n- Product Backlog adapted\n- Discussion of what to do next\n- Working session, not formal presentation\n\n**Key**: Inspect Increment and adapt Product Backlog\n\n### 7. Retrospective Creates Continuous Improvement\n\nEvery Sprint should improve something:\n- At least one high-priority improvement\n- Action items assigned to owners\n- Progress reviewed in next Retrospective\n- Safe environment for honest discussion\n\n**Anti-pattern**: Retrospectives without action items\n\n### 8. Protect the Sprint\n\nOnce Sprint Planning is complete:\n- No changes that endanger Sprint Goal\n- Product Owner cannot add work\n- Development Team commits to Sprint Goal\n- Scrum Master shields team from interference\n\n**Exception**: Sprint may be cancelled if Sprint Goal becomes obsolete\n\n### 9. Velocity is a Planning Tool\n\nVelocity helps with forecasting:\n- Average over recent sprints (e.g., last 3)\n- Used to forecast capacity\n- Improves over time as team matures\n- Never compared across teams\n\n**Anti-pattern**: Using velocity as performance metric\n\n### 10. Self-Organization is Key\n\nDevelopment Team decides how to do work:\n- No one tells team how to turn backlog into Increments\n- Team organizes itself around work\n- Collective accountability\n- Grows expertise and ownership\n\n**Scrum Master**: Facilitates, doesn't dictate\n\n## Sprint Burndown Chart\n\nThe Sprint Burndown shows remaining work throughout sprint:\n\n```\nStory Points\n40 |●\n   |  ●\n30 |    ●\n   |      ●         ●\n20 |        ●     ●\n   |          ● ●\n10 |            ●\n   |              ●\n 0 |________________●\n    1  2  3  4  5  6  7  8  9  10\n              Days\n\n    ● Actual    --- Ideal\n```\n\n**Ideal line**: Linear burn from start to zero\n**Actual line**: Team's actual progress\n**Analysis**:\n- Ahead of schedule: Actual below ideal\n- Behind schedule: Actual above ideal\n- Flat line: Work not being completed\n\n## Velocity Chart\n\nTrack velocity across sprints to improve forecasting:\n\n```\nStory Points\n40 |        ██\n35 |    ██  ██\n30 |    ██  ██  ██\n25 |    ██  ██  ██  ██\n20 |██  ██  ██  ██  ██  ██\n15 |██  ██  ██  ██  ██  ██\n10 |██  ██  ██  ██  ██  ██\n 5 |██  ██  ██  ██  ██  ██\n 0 |________________________\n    S1  S2  S3  S4  S5  S6\n\nAverage Velocity: 28 story points\nTrend: Improving (↑)\n```\n\n## Release Burndown\n\nTrack progress toward release across multiple sprints:\n\n```\nStory Points\n200 |●\n    |  ●\n150 |    ●\n    |      ●\n100 |        ●\n    |          ●\n 50 |            ●\n    |              ●\n  0 |________________●\n     S0 S1 S2 S3 S4 S5 S6\n           Sprints\n\nCompleted: 200 story points\nRemaining: 0 story points\nOn track for release\n```\n\n## Integration with Other Methodologies\n\n### Scrum + BDD\n\nUse BDD for backlog item specification:\n```javascript\n// 1. Create Product Backlog with Scrum\nconst scrumResult = await babysit({\n  process: 'methodologies/scrum',\n  inputs: { /* ... */ }\n});\n\n// 2. Use BDD for each Sprint's selected items\nfor (const pbi of sprint.sprintBacklog) {\n  const bddResult = await babysit({\n    process: 'methodologies/bdd-specification-by-example',\n    inputs: {\n      featureName: pbi.title,\n      userStory: pbi.userStory,\n      acceptanceCriteria: pbi.acceptanceCriteria\n    }\n  });\n}\n```\n\n### Scrum + TDD/ATDD\n\nUse TDD/ATDD for development within Sprint:\n```javascript\n// Scrum organizes sprints\n// TDD/ATDD guides development practices within sprint\n\nconst scrumResult = await babysit({\n  process: 'methodologies/scrum',\n  inputs: { /* ... */ }\n});\n\n// During sprint, use TDD for each task\nconst tddResult = await babysit({\n  process: 'methodologies/atdd-tdd',\n  inputs: {\n    features: sprint.sprintBacklog,\n    approach: 'tdd'\n  }\n});\n```\n\n### Scrum + Domain-Driven Design\n\nUse DDD for complex domain modeling:\n```javascript\n// 1. DDD for domain modeling (Product Backlog creation)\nconst dddModel = await babysit({\n  process: 'methodologies/domain-driven-design',\n  inputs: { /* ... */ }\n});\n\n// 2. Scrum for iterative delivery\nconst scrumResult = await babysit({\n  process: 'methodologies/scrum',\n  inputs: {\n    projectName: 'Complex Domain',\n    productVision: dddModel.vision,\n    // Use DDD insights for backlog\n  }\n});\n```\n\n### Scrum + XP Engineering Practices\n\nCombine Scrum framework with XP technical practices:\n- **Pair Programming**: During sprint development\n- **Test-Driven Development**: Red-Green-Refactor cycle\n- **Continuous Integration**: Multiple integrations per day\n- **Refactoring**: Improve design continuously\n- **Simple Design**: YAGNI principle\n- **Collective Code Ownership**: Anyone can improve any code\n\nThis combination is very common and effective.\n\n### Scrumban (Scrum + Kanban)\n\nBlend Scrum's timeboxing with Kanban's flow:\n- Keep Scrum events (Planning, Review, Retrospective)\n- Use Kanban board for visual workflow\n- Limit WIP (Work In Progress)\n- Continuous flow within sprint\n- Pull system instead of push\n\n## Comparison with Other Methodologies\n\n| Aspect | Scrum | Kanban | XP | FDD | Waterfall |\n|--------|-------|--------|-----|-----|-----------|\n| **Iterations** | Fixed sprints | Continuous flow | 1-2 week iterations | 2-week iterations | Phases |\n| **Planning** | Sprint Planning | Continuous | Weekly | Feature-based | Upfront |\n| **Roles** | 3 defined roles | No prescribed roles | 12 practices | Chief Programmers | Many roles |\n| **Change** | At sprint boundary | Anytime | Weekly | At iteration | Costly |\n| **Delivery** | End of sprint | Continuous | Continuous | End of iteration | End of project |\n| **Team Size** | 3-9 | Any | 2-12 | 15-500+ | Any |\n| **Best For** | Product development | Support/maintenance | Technical excellence | Large teams | Fixed requirements |\n| **Tracking** | Burndown charts | Cumulative Flow | Story board | Parking Lot | Gantt charts |\n| **Ownership** | Collective | Varies | Collective | Individual | Individual |\n\n## Common Challenges and Solutions\n\n### Challenge: Incomplete Sprint Backlog Items\n\n**Problem**: Stories not meeting Definition of Done by sprint end\n\n**Solutions**:\n- Break items into smaller pieces (no item larger than 1/3 of sprint)\n- Improve Definition of Ready (ensure items are well-understood)\n- Address impediments faster\n- Reduce scope in Sprint Planning\n- Improve estimates through practice\n\n### Challenge: Scope Creep During Sprint\n\n**Problem**: Product Owner adding work mid-sprint\n\n**Solutions**:\n- Reinforce Sprint sanctity (no changes endangering goal)\n- Product Owner can add to Product Backlog, not Sprint Backlog\n- If critical, may need to end sprint and replan\n- Clear Sprint Goal helps resist scope creep\n- Educate stakeholders on Scrum principles\n\n### Challenge: Low Velocity\n\n**Problem**: Team completing fewer story points than expected\n\n**Solutions**:\n- Check for technical debt slowing team\n- Identify and remove impediments\n- Improve Definition of Done (may be unrealistic)\n- Team may be over-estimating\n- Ensure team has all needed skills\n- Look for external interruptions\n\n### Challenge: Ineffective Daily Scrums\n\n**Problem**: Daily Scrums becoming status reports or too long\n\n**Solutions**:\n- Stand up (keeps meeting short)\n- Focus on Sprint Goal, not status\n- Scrum Master timeboxes to 15 minutes\n- Deep discussions taken offline\n- Same time and place daily\n- Development Team only (others observe)\n\n### Challenge: Sprint Review Without Stakeholders\n\n**Problem**: No stakeholders attend Sprint Review\n\n**Solutions**:\n- Product Owner must invite stakeholders\n- Demo real, working software\n- Make it interactive working session\n- Show value delivered\n- Schedule at convenient time\n- Emphasize importance to product success\n\n### Challenge: Retrospectives Without Action\n\n**Problem**: Same issues every retrospective, no improvement\n\n**Solutions**:\n- Ensure action items assigned to owners\n- Review previous action items first\n- Focus on 1-2 high-priority improvements\n- Make improvements visible\n- Hold team accountable\n- Change retrospective format if stale\n\n### Challenge: Technical Debt Accumulating\n\n**Problem**: Code quality declining, velocity dropping\n\n**Solutions**:\n- Strengthen Definition of Done\n- Allocate capacity for technical work (e.g., 20% of sprint)\n- Make technical debt visible on Product Backlog\n- Never compromise Definition of Done for velocity\n- Refactoring is part of done, not separate item\n\n## Scrum Myths Debunked\n\n### Myth 1: \"Scrum means no documentation\"\n\n**Reality**: Scrum values working software over documentation, but doesn't prohibit it. Definition of Done typically includes necessary documentation.\n\n### Myth 2: \"Scrum Master is project manager\"\n\n**Reality**: Scrum Master is servant-leader and coach, not manager. Has no authority over team, facilitates rather than directs.\n\n### Myth 3: \"Scrum eliminates planning\"\n\n**Reality**: Scrum has multiple planning events (Sprint Planning, backlog refinement, Daily Scrum). Planning is continuous, not just upfront.\n\n### Myth 4: \"Velocity should always increase\"\n\n**Reality**: Velocity stabilizes as team matures. Always increasing velocity may indicate poor estimates or technical debt accumulation.\n\n### Myth 5: \"Sprint Review is just a demo\"\n\n**Reality**: Sprint Review is collaborative working session to inspect Increment and adapt Product Backlog, not just a presentation.\n\n### Myth 6: \"Can't change Product Backlog during Sprint\"\n\n**Reality**: Product Owner can change Product Backlog anytime. Just can't change Sprint Backlog.\n\n### Myth 7: \"Scrum means no design\"\n\n**Reality**: Design happens continuously. Architecture emerges through refinement and development. Definition of Done ensures design quality.\n\n### Myth 8: \"Daily Scrum must use three questions\"\n\n**Reality**: Three questions are common pattern, not rule. Team can use any format that achieves daily synchronization.\n\n## References\n\n### Official Resources\n\n- [Scrum Guide (Official)](https://scrumguides.org/) - The definitive guide to Scrum\n- [Scrum.org](https://www.scrum.org/) - Ken Schwaber's organization\n- [Scrum Alliance](https://www.scrumalliance.org/) - Jeff Sutherland's organization\n- [2020 Scrum Guide](https://scrumguides.org/scrum-guide.html) - Latest version\n\n### Books\n\n- **\"Scrum: The Art of Doing Twice the Work in Half the Time\"** by Jeff Sutherland - Co-creator's perspective\n- **\"The Scrum Guide\"** by Ken Schwaber and Jeff Sutherland - Official guide (free)\n- **\"Agile Estimating and Planning\"** by Mike Cohn - Planning and estimation\n- **\"User Stories Applied\"** by Mike Cohn - Writing effective user stories\n- **\"Succeeding with Agile\"** by Mike Cohn - Implementing Scrum\n- **\"The Professional Product Owner\"** by Don McGreal and Ralph Jocham - Product Owner role\n- **\"Scrum Mastery\"** by Geoff Watts - Scrum Master role\n\n### Articles & Guides\n\n- [Monday.com Scrum Guide 2026](https://monday.com/blog/project-management/scrum/)\n- [Atlassian Scrum Resources](https://www.atlassian.com/agile/scrum)\n- [Mountain Goat Software](https://www.mountaingoatsoftware.com/) - Mike Cohn's resources\n- [Scrum.org Resources](https://www.scrum.org/resources)\n\n### Academic Papers\n\n- Schwaber, K., & Sutherland, J. (2020). \"The Scrum Guide\"\n- Schwaber, K. (1995). \"SCRUM Development Process\"\n- Rising, L., & Janoff, N. S. (2000). \"The Scrum Software Development Process for Small Teams\"\n\n### Training & Certification\n\n- [Professional Scrum Master (PSM)](https://www.scrum.org/assessments/professional-scrum-master-i-certification) - Scrum.org\n- [Certified ScrumMaster (CSM)](https://www.scrumalliance.org/get-certified/scrum-master-track/certified-scrummaster) - Scrum Alliance\n- [Professional Scrum Product Owner (PSPO)](https://www.scrum.org/assessments/professional-scrum-product-owner-i-certification)\n\n## Troubleshooting\n\n### Sprints Feel Chaotic\n\n**Symptoms**: Constant firefighting, no rhythm\n\n**Diagnosis**: Likely weak Definition of Done, poor backlog refinement, or too many interruptions\n\n**Solutions**:\n1. Strengthen Definition of Done\n2. Invest in backlog refinement (10% of capacity)\n3. Scrum Master shields team from interruptions\n4. Ensure Sprint Goal is clear and focused\n\n### Velocity Unpredictable\n\n**Symptoms**: Wide swings in velocity sprint-to-sprint\n\n**Diagnosis**: Inconsistent estimating, changing team, or technical debt\n\n**Solutions**:\n1. Improve estimation through practice and calibration\n2. Keep team stable (no constant changes)\n3. Address technical debt\n4. Ensure items are well-understood before commitment\n\n### Team Waiting for Approval\n\n**Symptoms**: Work blocked waiting for Product Owner decisions\n\n**Solutions**:\n1. Product Owner must be available (not 5% role)\n2. Acceptance criteria clear before Sprint Planning\n3. Definition of Ready for backlog items\n4. Product Owner empowered to make decisions\n\n### No Improvement Sprint-to-Sprint\n\n**Symptoms**: Same problems every sprint\n\n**Solutions**:\n1. Take Retrospective action items seriously\n2. Assign owners and due dates\n3. Review progress on improvements\n4. Focus on 1-2 high-priority improvements\n5. Make improvements visible\n\n## License\n\nThis methodology implementation is part of the Babysitter SDK and follows the same license terms.\n\n## Contributing\n\nTo improve this Scrum implementation:\n1. Review the backlog in `methodologies/backlog.md`\n2. Propose enhancements via issues\n3. Submit pull requests with improvements\n4. Share real-world usage experiences\n\n---\n\n**Implementation Status**: ✅ Implemented\n**Last Updated**: 2026-01-23\n**Version**: 1.0.0\n**Based On**: Scrum Guide 2020\n",
    "documents": [
      "specialization:scrum"
    ]
  },
  "outgoingEdges": [
    {
      "from": "page:library-scrum",
      "to": "specialization:scrum",
      "kind": "documents"
    }
  ],
  "incomingEdges": [
    {
      "from": "page:index",
      "to": "page:library-scrum",
      "kind": "contains_page"
    }
  ]
}