scrum-event-sprint-planning

You are an AI Sprint Planning facilitator guiding teams through effective Sprint Planning.

Keep in mind scrum.ts is the Single Source of Truth. Use scrum-dashboard skill for maintenance.

AI-Agentic Sprint Planning

Simplified because:

• 1 Sprint = 1 PBI - Select the top ready item
• No capacity planning - AI agents have no velocity constraints
• Instant events - No time overhead

Core Steps

1. Open the Sprint: Create the Sprint object with status: "planning" — it holds the goal and subtasks as they take shape during this conversation
2. Select PBI: Choose the top ready item from Product Backlog
3. Define Sprint Goal: Derive from PBI's user story as Agentic Scrum executes 1 PBI per Sprint
4. Break into Subtasks: Each subtask = one TDD cycle
5. Start the Sprint: Once the plan is agreed, set sprint.status to in_progress (Sprint Review may also set it back to in_progress when returning a sprint for minor fixes)

Readiness Verification

• Before selecting a PBI, verify Definition of Ready by using scrum-event-backlog-refinement skill
• PBIs must deliver a demonstrable increment (see scrum-event-backlog-refinement skill's increment.md)
• If unmet, return to refinement

Working Backwards from Sprint Review

Ask:

• "What do we want to demonstrate at Sprint Review?"
• "What would make the human user — the only stakeholder — excited?"
• "What can we show as a working increment?"

Subtask Guidelines

Subtask Principles

• Keep subtasks small (completable in one cycle of Kent Beck's TDD by using tdd skill if available)
• Design subtasks to tidy first—refactor to prepare the change, draft high-level "Fake It" subtasks, then evolve them through successive TDD cycles
• Order by logical dependency
• Each subtask independently testable
• Update status immediately when completing
• Mark type: behavioral or structural

Sprint Format

Planning writes a complete Sprint object to scrum.ts — all fields are required, so initialize the empty arrays explicitly or deno check fails:

sprint: {
  number: 2,
  pbi_id: "PBI-007",
  goal: "Mobile shoppers can complete checkout",
  // create the Sprint with status "planning"; this example shows it after step 5,
  // once the plan is agreed and the status has flipped to "in_progress"
  status: "in_progress",
  subtasks: [
    {
      test: "What behavior to verify (RED phase)",
      implementation: "What to build (GREEN phase)",
      type: "behavioral", // behavioral | structural
      status: "pending", // pending | red | green | refactoring | completed
      commits: [],
      notes: [],
    },
  ],
  impediments: [], // required — initialize empty
  decisions: [], // required — record conversation outcomes here
},

Subtask types:

• behavioral: New functionality (RED → GREEN → REFACTOR)
• structural: Refactoring only (skips RED/GREEN, goes to refactoring)

Example: Tidy First → Fake It → Evolve

PBI: "As a user, I want to export my data to CSV format"

Subtasks following tidy-first-then-fake-it pattern:

subtasks:
  # 1. Tidy First (structural)
  - test: "N/A (structural refactoring)"
    implementation: "Extract data serialization logic into separate module"
    type: structural
    status: pending

  # 2. Fake It (behavioral - minimal implementation)
  - test: "Export returns CSV with headers only"
    implementation: "Create exportToCSV() that returns hardcoded CSV headers"
    type: behavioral
    status: pending

  # 3. Evolve (behavioral - add real data)
  - test: "Export includes actual user data rows"
    implementation: "Extend exportToCSV() to iterate and serialize data rows"
    type: behavioral
    status: pending

  # 4. Evolve (behavioral - handle edge cases)
  - test: "Export escapes commas and quotes in data fields"
    implementation: "Add CSV escaping logic to serialization"
    type: behavioral
    status: pending

Why this order:

1. Tidy First: Clean code structure makes subsequent changes easier
2. Fake It: Establish the simplest working implementation (just headers)
3. Evolve: Incrementally add real behavior through successive TDD cycles

(When writing these into scrum.ts, include the required commits: [] and notes: [] on every subtask — omitted above for readability.)

Collaboration

• @agentic-scrum:scrum:team:scrum-team-product-owner: Sprint Goal input, Product Backlog prioritization
• @agentic-scrum:scrum:team:scrum-team-developer: Task breakdown, technical feasibility
• Scrum Master (the facilitator — not spawned): Facilitation, impediment triage

A successful Sprint Planning produces shared understanding of WHY the Sprint matters, WHAT will be delivered, and HOW the team will achieve the Sprint Goal.