---
name: scrum-event-sprint-planning
description: Guide Sprint Planning in AI-Agentic Scrum. Use when selecting PBI, defining Sprint Goal, or breaking into subtasks.
---

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

**Single Source of Truth**: `scrum.ts` in project root. 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. **Select PBI**: Choose the top `ready` item from Product Backlog
2. **Define Sprint Goal**: Based on the PBI's benefit statement
3. **Break into Subtasks**: Each subtask = one TDD cycle

## Subtask Format

Each subtask in `scrum.ts` should follow TDD structure:

```yaml
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: []
```

**Subtask types**:
- `behavioral`: New functionality (RED → GREEN → REFACTOR)
- `structural`: Refactoring only (skips RED/GREEN, goes to refactoring)

## Sprint Goal Excellence

**Characteristics**:
- **Evaluable**: Can clearly determine if achieved
- **Stakeholder-Understandable**: Meaningful outside the team
- **Outcome-Focused**: Value delivered, not tasks completed
- **Fixed**: Does not change during Sprint

**Anti-Patterns**:
- "Complete all Sprint Backlog items" (not a goal)
- "Finish Stories A, B, and C" (output-focused)
- Goals only developers understand

## Readiness Verification

Before selecting a PBI, verify Definition of Ready:
- [ ] Clear user story with role, action, benefit
- [ ] Acceptance criteria specific and testable
- [ ] Dependencies identified and resolved
- [ ] No blocking questions remaining
- [ ] Has executable verification commands

## Subtask Guidelines

- Keep subtasks small (completable in one TDD cycle)
- Order by logical dependency
- Each subtask independently testable
- Update status immediately when completing
- Mark `type`: `behavioral` or `structural`

## Working Backwards from Sprint Review

Ask:
- "What do we want to demonstrate at Sprint Review?"
- "What would make stakeholders excited?"
- "What can we show as a working increment?"

## Collaboration

- **@scrum-team-product-owner**: Sprint Goal input, Product Backlog prioritization
- **@scrum-team-developer**: Task breakdown, technical feasibility
- **@scrum-team-scrum-master**: Facilitation, impediment removal

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.