Collection

---
name: .claude/skills/sprint-planning/SKILL.md
description: |
  効果的なスプリント計画の立案と実行管理手法。
  チームが一丸となって価値を提供できる明確な目標と実行計画を策定します。

  専門分野:
  - スプリントゴール設定: SMART目標、価値ベースのゴール定義
  - キャパシティプランニング: ベロシティ、可用性、バッファ計算
  - タスク分解: ユーザーストーリー分解、見積もり、依存関係管理
  - コミットメント: チーム合意、リスク評価、調整メカニズム

  📚 リソース参照:
  このスキルには以下のリソースが含まれています。
  必要に応じて該当するリソースを参照してください:

  - `.claude/skills/sprint-planning/resources/capacity-planning.md`: チームキャパシティ計算の詳細ガイド（計算式、調整要因、ツール活用）
  - `.claude/skills/sprint-planning/templates/sprint-plan-template.md`: スプリント計画標準テンプレート（ゴール、キャパシティ、リスク、成功基準含む）
  - `.claude/skills/sprint-planning/scripts/calculate-capacity.mjs`: キャパシティ自動計算ツール（Node.js実行可能、ストーリーポイント変換）

  使用タイミング:
  - スプリント開始時の計画セッション
  - キャパシティプランニング時
  - スプリントゴールの設定時
  - タスク分解とコミットメント時

  Use proactively when planning sprints, estimating capacity,
  or setting team commitments for iteration goals.
version: 1.0.0
---

# スプリント計画スキル

## 概要

スプリント計画を通じて、チームが一丸となって価値を提供できる
明確な目標と実行計画を策定し、予測可能な成果を実現します。

## いつ使うか

- スプリント開始時の計画セッション
- キャパシティプランニング
- スプリントゴールの設定
- タスク分解とコミットメント
- 中間レビューと調整

## スプリント計画プロセス

### Part 1: What（何を）- 2 時間

#### スプリントゴール設定

```
良いスプリントゴールの特性:
- 明確で測定可能
- 1文で表現可能
- チーム全体で達成
- ビジネス価値に直結
- 柔軟性を残す

例:
✓ 「新規ユーザーが5分以内に初回購入を完了できるようにする」
✓ 「APIレスポンスタイムを200ms以下に改善する」
✗ 「バックログアイテム1-10を完了する」（価値が不明確）
```

#### バックログアイテム選択

```
選択プロセス:
1. プロダクトオーナーが優先順位を説明
2. チームがキャパシティを確認
3. ベロシティを参考に選択
4. 依存関係を考慮
5. リスクバッファを確保
6. スプリントゴールとの整合性確認
```

### Part 2: How（どのように）- 2 時間

#### タスク分解

```
分解の粒度:
- 1タスク = 1日以内
- 理想は2-4時間
- 具体的なアクション
- 完了条件明確

タスクタイプ:
- 設計/分析
- 実装/コーディング
- テスト作成
- レビュー
- ドキュメント
- デプロイ
```

#### 工数見積もり

```
手法:
- 理想時間での見積もり
- 実効時間への変換（×1.5-2.0）
- ペアプロ/モブプロ考慮
- 会議/サポート時間考慮

キャパシティ計算:
利用可能時間 =
  (作業日数 × 8時間 - 会議時間)
  × フォーカスファクター(0.6-0.8)
  × 出勤率
```

## キャパシティプランニング

### チームキャパシティ

```
個人キャパシティ算出:
基本: 8時間/日
会議: -2時間/日
サポート: -1時間/日
フォーカス: 5時間 × 0.7 = 3.5時間
スプリント: 3.5時間 × 10日 = 35時間

チーム合計:
メンバー数 × 個人キャパシティ × 出勤率
```

### 休暇とイベント考慮

```yaml
capacity_adjustments:
  holidays:
    - 祝日: -8時間/人

  vacations:
    - 休暇予定: 個別調整

  events:
    - 研修: -4時間
    - カンファレンス: -8時間
    - 全体会議: -2時間

  buffer:
    - 緊急対応: 10%
    - 技術的負債: 20%
```

## スプリントゴールパターン

### 機能追加型

```
ゴール: 「[機能名]を実装し、[ユーザー]が[価値]を得られるようにする」

成功基準:
- 機能が本番環境で利用可能
- パフォーマンス基準を満たす
- ユーザーテスト合格
```

### 改善型

```
ゴール: 「[メトリクス]を[現在値]から[目標値]に改善する」

成功基準:
- 測定可能な改善
- 他機能への影響なし
- ロールバック可能
```

### 技術的負債返済型

```
ゴール: 「[技術的負債]を解消し、[効果]を実現する」

成功基準:
- リファクタリング完了
- テストカバレッジ向上
- パフォーマンス改善
```

### 実験/学習型

```
ゴール: 「[仮説]を検証し、[次の意思決定]のためのデータを収集する」

成功基準:
- 実験実施
- データ収集完了
- 意思決定可能
```

## コミットメント戦略

### 予測可能性の向上

```
Yesterday's Weather:
- 前スプリントの完了量を基準
- 徐々に調整
- 安定したベロシティ

ストレッチゴール:
- コア目標: 80%のキャパシティ
- ストレッチ: +20%
- バッファ確保
```

### リスク管理

```
リスクレベル:
High: 新技術、外部依存
Medium: 複雑な統合、大規模変更
Low: 既知の領域、小規模変更

対策:
- High → スパイク実施、バッファ確保
- Medium → ペアプロ、早期着手
- Low → 通常プロセス
```

## スプリント実行管理

### デイリースクラム最適化

```
効果的な形式:
1. ウォークザボード
   - カンバンボードを右から左へ
   - ブロッカー優先
   - フロー重視

2. 三つの質問（改良版）
   - ゴール達成の進捗は？
   - 今日のフォーカスは？
   - 支援が必要なことは？
```

### スプリント中の調整

```
調整が必要な場合:
- 重大なブロッカー発生
- メンバーの急な不在
- 緊急要件の発生
- 見積もりの大幅な誤り

対応:
1. スコープ調整（PO協議）
2. ゴール優先度の再確認
3. ヘルプ要請
4. 次スプリントへの持ち越し
```

### バーンダウン管理

```
健全なパターン:
- 理想線に沿った減少
- 小さな上下変動
- 終盤での収束

警告サイン:
- 平坦な線（進捗なし）
- 急激な上昇（スコープ追加）
- 階段状（バッチ作業）
- 最終日の急降下（品質リスク）
```

## スプリントレビュー準備

### デモ準備

```
チェックリスト:
□ デモ環境準備
□ テストデータ用意
□ シナリオ作成
□ 発表者決定
□ 時間配分
□ バックアッププラン
```

### ステークホルダー招待

```
招待タイミング:
- 2日前: カレンダー招待
- 1日前: アジェンダ送付
- 当日朝: リマインダー

含める情報:
- スプリントゴール
- 完了予定アイテム
- デモの見どころ
- フィードバック要望点
```

## レトロスペクティブ連携

### メトリクス準備

```
収集データ:
- ベロシティ実績
- 完了/未完了アイテム
- バーンダウンチャート
- 品質メトリクス
- チーム満足度
```

### 改善アクション

```
カテゴリー:
- プロセス改善
- ツール導入
- コミュニケーション
- 技術的改善
- チーム文化

実施方法:
- 次スプリントに組み込み
- 改善バックログ作成
- 担当者アサイン
- 効果測定方法決定
```

## ツールとテンプレート

### スプリント計画シート

```markdown
# Sprint [番号] Planning

## Sprint Goal

[明確な 1 文のゴール]

## Capacity

- Available Days: [日数]
- Team Members: [人数]
- Total Hours: [時間]
- Focus Factor: [%]
- Effective Capacity: [時間]

## Selected Items

| Item | Points | Priority | Owner |
| ---- | ------ | -------- | ----- |
|      |        |          |       |

## Risks & Dependencies

- Risk 1: [説明] - Mitigation: [対策]
- Dependency 1: [説明] - Status: [状態]

## Success Criteria

- [ ] [具体的な成功基準]
- [ ] [測定可能な指標]

## Notes

[その他の注意事項]
```

### キャパシティ計算ツール

```python
def calculate_capacity(team_size, sprint_days,
                       meetings_per_day=2,
                       focus_factor=0.7,
                       availability_rate=0.9):
    """
    スプリントキャパシティ計算
    """
    hours_per_day = 8
    meeting_hours = meetings_per_day

    effective_hours_per_day = (
        (hours_per_day - meeting_hours) * focus_factor
    )

    total_capacity = (
        team_size *
        effective_hours_per_day *
        sprint_days *
        availability_rate
    )

    return {
        'total_hours': total_capacity,
        'story_points': total_capacity / 6,  # 仮定: 1pt = 6h
        'buffer_hours': total_capacity * 0.2
    }
```

## アンチパターンと対策

### 過剰コミット

**症状**: 毎回スプリントゴール未達成
**対策**: Yesterday's Weather 適用、バッファ確保

### 曖昧なゴール

**症状**: チームの方向性バラバラ
**対策**: SMART 原則適用、1 文ルール

### タスク未分解

**症状**: 進捗が見えない、終盤で問題発覚
**対策**: 1 日以内ルール徹底

## チェックリスト

### 計画セッション前

- [ ] バックログはリファインメント済みか
- [ ] チームの予定は確認したか
- [ ] 前スプリントの振り返りは完了か
- [ ] ステークホルダー要望は把握済みか

### 計画セッション中

- [ ] スプリントゴールは明確か
- [ ] キャパシティは現実的か
- [ ] 全員がコミットしているか
- [ ] リスクは特定されているか

### 計画セッション後

- [ ] 計画は文書化されたか
- [ ] タスクはツールに登録されたか
- [ ] カレンダーは更新されたか
- [ ] ステークホルダーに共有したか

## 関連スキル

- `.claude/skills/backlog-management/SKILL.md` - バックログ準備
- `.claude/skills/estimation-techniques/SKILL.md` - 見積もり
- `.claude/skills/metrics-tracking/SKILL.md` - 実績測定
- `.claude/skills/agile-project-management/SKILL.md` - スクラム実践