Agile Sprint Planning

Sprint Planning Automation

Core Principles

1. Transparency Enables Collaboration: Sprint plan is visible to all, with objectives, Story assignments, and capacity matching information transparent
2. Risk Early Identification: Identify risks and dependencies during Sprint Planning, rather than discovering issues during execution
3. Automated Tracking: Sprint progress and Story status are automatically tracked, reducing manual reporting burden

Interaction Mode

🤖→👤 AI Suggests, Human Approves

• AI automatically completes Step 1-5, generating a complete Sprint plan
• Human review focus: Sprint Goal accuracy, Story selection reasonableness, capacity appropriateness
• Human can request AI adjustments, AI regenerates
• After Product Owner approval, the Sprint officially begins

---

Input

| Input Item | Type | Required | Source | Description | |--------|------|------|------|------| | productbacklog | object[] | Yes | output/pm-monitoring/iteration-backlog-grooming/prioritizeditems | Product backlog | | sprintgoal | string | ○ | User provided | Sprint goal description | | teamcapacity | object | Yes | output/pm-project/planning-resource/resourceplan | Team capacity data | | sprintduration_days | number | Yes | User provided | Sprint duration in days |

---

Execution Steps

Step 1: Sprint Goal Auto-suggestion [Core]

Actions:

• Analyze high-priority Stories in Product Backlog
• Identify themes or feature areas
• Generate 1-2 sentence Sprint Goal
• Ensure Goal is specific, measurable, and valuable

Output:

{
  "sprint_goal_suggestion": {
    "goal": "string",
    "focus_area": "string",
    "success_indicator": "string",
    "confidence": 0.0-1.0
  }
}

Step 2: Story Auto-selection [Core]

Actions:

• Sort Backlog Stories by priority
• Consider dependencies between Stories
• Match Stories with team capabilities
• Greedy algorithm to select optimal combination up to capacity limit

Output:

{
  "selected_stories": [{
    "id": "STORY-001",
    "title": "string",
    "priority": "P0 | P1 | P2 | P3",
    "dependencies": ["STORY-ID"],
    "estimated_points": number,
    "recommended_assignee": "string | null",
    "selection_reason": "string"
  }],
  "rejected_stories": [{
    "id": "string",
    "reason": "string"
  }],
  "selection_confidence": 0.0-1.0
}

Step 3: Workload Auto-estimation [Core]

Actions:

• Estimate Story Points for each selected Story
• Use Planning Poker or T-Shirt Size as reference
• Consider technical complexity and uncertainty
• Summarize total points

Output:

{
  "story_points_estimation": [{
    "story_id": "STORY-001",
    "title": "string",
    "story_points": number,
    "estimation_method": "fibonacci | t-shirt | ai-suggested",
    "confidence": 0.0-1.0,
    "notes": "string"
  }],
  "total_story_points": number,
  "velocity_reference": number,
  "estimation_confidence": 0.0-1.0
}

Step 4: Capacity Matching Validation [Core]

Actions:

• Calculate team available capacity (person-days × team size)
• Compare planned points with capacity
• Validate within safe range (recommend 80% utilization)
• If exceeding capacity, suggest adjustments

Output:

{
  "capacity_validation": {
    "team_capacity": {
      "total_available_hours": number,
      "story_points_capacity": number,
      "recommended_utilization": 0.0-1.0
    },
    "sprint_plan": {
      "planned_story_points": number,
      "planned_hours": number,
      "utilization_rate": 0.0-1.0
    },
    "validation_result": "green | yellow | red",
    "validation_message": "string",
    "adjustment_suggestions": ["string"]
  }
}

Step 5: Sprint Plan Document Generation [Core]

Actions:

• Integrate outputs from the above steps
• Generate complete Sprint plan document
• Include risk alerts and recommendations
• Prepare human approval version

Output:

# sprint_plan

## Sprint Information
- Sprint Number:
- Sprint Goal:
- Start Date:
- End Date:
- Team:

## Sprint Goal
{Step 1 Output}

## Planned Stories
{Step 2 & 3 Output}

## Capacity Validation
{Step 4 Output}

## Risks & Recommendations
- Identified risks:
- Recommended focus areas:

## Approval
- Approval Status: Pending

---

Output Depth Grading

| Depth Level | Output Scope | Description | |----------|----------|------| | quick | Sprint plan and Story allocation | Core conclusions + minimum viable deliverable | | standard | Full deliverables (current default) | Complete deliverables including all Step outputs | | deep | Full plan + risk buffer design + dependency analysis + capacity optimization suggestions | Full deliverables + extended analysis + deep simulation |

Output

Storage Path: output/pm-project/agile-sprint-planning/

Output Files: sprint_plan.json, metadata.json

Output Schema:

{
  "type": "object",
  "required": ["sprint_plan", "metadata"],
  "properties": {
    "sprint_plan": {"type": "object", "description": "Sprint plan including objectives, Story list, capacity validation, and risks"},
    "metadata": {"type": "object", "description": "Metadata including Sprint ID, confidence, and approval status"}
  }
}

Output Validation Rules

| Field Path | Type | Required | Description | |----------|------|------|------| | sprintplan.sprintgoal | string | Yes | Sprint goal description, must be specific and measurable | | sprintplan.stories | array | Yes | Planned Story list, each must contain id, title, storypoints, assignee | | sprintplan.stories[].storypoints | number | Yes | Story point estimate, must be positive integer | | sprintplan.stories[].status | string | Yes | Story status, enum value planned | | sprintplan.capacityvalidation.status | string | Yes | Capacity validation result, enum values green/yellow/red | | sprintplan.capacityvalidation.message | string | Yes | Validation explanation message | | sprintplan.risks | array | No | Risk list, each must contain description and priority | | sprintplan.risks[].priority | string | Yes | Risk priority, enum values high/medium/low | | metadata.sprintid | string | Yes | Sprint unique identifier | | metadata.generatedat | string | Yes | Generation time, ISO 8601 format | | metadata.confidence | number | Yes | Overall confidence, range 0.0-1.0 | | metadata.humanapprovalrequired | boolean | Yes | Whether human approval is required, must be true for Sprint Planning | | metadata.approvalstatus | string | Yes | Approval status, enum values pending/approved/rejected |

{
  "sprint_plan": {
    "sprint_goal": "string",
    "stories": [{
      "id": "string",
      "title": "string",
      "story_points": number,
      "assignee": "string",
      "status": "planned"
    }],
    "capacity_validation": {
      "status": "green | yellow | red",
      "message": "string"
    },
    "risks": [{
      "description": "string",
      "priority": "high | medium | low"
    }]
  },
  "metadata": {
    "sprint_id": "string",
    "generated_at": "ISO datetime",
    "confidence": 0.0-1.0,
    "human_approval_required": true,
    "approval_status": "pending | approved | rejected"
  }
}

---

Capacity Calculation Rules

Available Capacity = Team Size × Available Hours Per Person Per Day × Sprint Days × Utilization Factor

Recommended Configuration:
- Utilization Factor: 0.8 (reserve 20% for meetings, ad-hoc tasks)
- Available Hours Per Person Per Day: 6 hours (not 8 hours)

---

Decision Rules

| Condition | Action | |------|------| | Backlog Stories 100%) | Mandatory requirement to reduce Stories or extend Sprint | | Complex dependencies preventing selection | Output multiple options, escalate to human decision | | Story estimation confidence < 0.5 | Mark uncertainty, escalate to team for confirmation |

Quality Checks

P0 Checks (must pass for quick/standard/deep)

• [ ] Sprint Goal is clear and contains ≥1 quantifiable acceptance criteria
• [ ] Selected Stories total points ≤ team available capacity × 1.1 (10% buffer reserved)

P1 Checks (must pass for standard/deep)

• [ ] 100% of cross-team dependencies identified with resolution plan or timeline
• [ ] Each Story estimate confirmed by ≥2 team members
• [ ] Sprint includes ≥1 tech debt or improvement item (if backlog exists)
• [ ] No P0 risks excluded from Sprint consideration

P2 Checks (must pass for deep only)

• [ ] Extended analysis complete (deep simulation and roadmap generated)
• [ ] Decision records complete (key decisions have rationale and alternatives)

Degradation Strategy

Upstream File Missing Degradation Plan

| Missing Upstream Input | Degradation Plan | Output Impact | |---------------|---------|---------| | Product Backlog | User provides requirements list (title + priority + estimate), AI generates Sprint plan accordingly | Sprint plan generated from user input, lacking structured Backlog data support | | Sprint goal | AI infers Sprint Goal from high-priority Stories, marks for PO confirmation | Sprint Goal is AI-inferred, requires Product Owner confirmation before execution | | Team capacity | Skip capacity validation, mark "Requires manual confirmation of capacity matching" in plan | Sprint plan has no capacity validation result, requires manual supplementation | | Sprint duration | If user does not provide Sprint days, prompt user to provide or skip related steps | Capacity calculation and scheduling lack time range, requires manual supplementation |

Data Acquisition Instructions

When upstream files are missing, obtain necessary data through the following methods:

1. Product Backlog missing: Ask user to provide requirements list, including requirement title, priority (P0-P3), and rough estimate; AI will perform Story selection and Sprint plan generation accordingly
2. Sprint goal missing: AI will infer Sprint Goal from highest priority Stories, mark in output "AI-inferred, requires Product Owner confirmation"
3. Team capacity missing: Skip capacity matching validation step, mark in Sprint plan "Requires manual confirmation of team capacity support", suggest confirming with team before submitting for approval

Upstream Change Response

Upstream Change Impact Table

| Upstream Change | Impact Scope | Response Strategy | |----------|----------|----------| | Product Backlog change (priority adjustment/Story additions/removals) | Story selection results, Sprint Goal suggestion | Re-execute Story selection, update Sprint plan and Goal suggestion | | Team capacity change (personnel changes/holiday adjustments) | Capacity validation results, Story selection upper limit | Recalculate capacity, adjust Story selection and capacity validation | | Sprint duration adjustment | Capacity calculation, scheduling timeline | Recalculate available capacity, update Sprint plan time range |

Downstream Notification Mechanism Table

| Change Type | Impact Scope | Notification Method | |----------|----------|----------| | Sprint plan change (Story additions/removals/Goal adjustment) | Daily sync, Sprint review, risk management | Update sprintplan.json, notify agile-daily-sync, agile-review, risk-management | | Capacity validation result change | Resource planning, team scheduling | Update sprintplan.json, notify planning-resource | | Approval status change | All downstream Pipelines dependent on Sprint plan | Update metadata.json, notify all downstream consumers |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: LuckyOneTwoThree
• Source: LuckyOneTwoThree/vibe-skill
• License: MIT
• Homepage: https://luckyonetwothree.github.io/all-skill-html/

Install and usage instructions live in the source repository linked above.