majiayu000 スプリント計画スキル
概要
スプリント計画を通じて、チームが一丸となって価値を提供できる 明確な目標と実行計画を策定し、予測可能な成果を実現します。
いつ使うか
- スプリント開始時の計画セッション
- キャパシティプランニング
- スプリントゴールの設定
- タスク分解とコミットメント
- 中間レビューと調整
スプリント計画プロセス
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時間
チーム合計:
メンバー数 × 個人キャパシティ × 出勤率
休暇とイベント考慮
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日前: アジェンダ送付
- 当日朝: リマインダー
含める情報:
- スプリントゴール
- 完了予定アイテム
- デモの見どころ
- フィードバック要望点
レトロスペクティブ連携
メトリクス準備
収集データ:
- ベロシティ実績
- 完了/未完了アイテム
- バーンダウンチャート
- 品質メトリクス
- チーム満足度
改善アクション
カテゴリー:
- プロセス改善
- ツール導入
- コミュニケーション
- 技術的改善
- チーム文化
実施方法:
- 次スプリントに組み込み
- 改善バックログ作成
- 担当者アサイン
- 効果測定方法決定
ツールとテンプレート
スプリント計画シート
# 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
[その他の注意事項]
キャパシティ計算ツール
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- スクラム実践