sprint-planning

スプリント計画

概要

スプリント計画スキルを使うと、プロダクトマネージャーやエンジニアリングリーダーは、成果の提供と品質のバランスを取りながら、効果的なスプリントに作業をまとめられます。継続的な改善に向けた目標設定、キャパシティ計画、ストーリーの見積もり、振り返り分析を扱います。

このスキルを使用する場面

• 2週間または1週間のスプリントを計画するとき
• 機能の複雑さと作業量を見積もるとき
• 機能開発と技術的負債のバランスを取るとき
• 現実的なスプリントのコミットメントを設定するとき
• 効果的なスプリントキックオフを実施するとき
• 生産的な振り返りを実施するとき
• チームのベロシティとプロセスを改善するとき

スプリント計画フレームワーク

計画前の準備（1週間前）

ステップ1：バックログの整理

• バックログ上位20件を確認する
• 各項目に明確な受け入れ基準があることを確認する
• 曖昧な要件があればPMに確認する
• 大きな項目を2～4ポイントのストーリーに分割する
• 依存関係とブロッカーを記録する
• 優先順位を更新する

ステップ2：キャパシティ計画

• 利用可能な人日を数える（合計日数－予定された有給休暇）
• 会議やその他の間接業務を考慮する（通常20％）
• 開発作業に使える正味キャパシティを計算する
• 特定の分野に注力するチームメンバーを把握する

ステップ3：依存関係の確認

• 前のスプリントから持ち越されたブロック項目を特定する
• ブロック解除の作業を優先する
• 外部依存関係（デザイン、サードパーティ）に注意喚起する
• 外部要因による遅延への回避策を計画する

---

ストーリーポイントの見積もり

見積もりフレームワーク（フィボナッチ数列）

ストーリーポイントは相対的な複雑さ／作業量を表すものであり、時間ではありません

1 point    - Trivial changes: typo fixes, simple config updates
           Example: "Fix button color from blue to red"

2 points   - Simple changes: straightforward feature, 1-2 day effort
           Example: "Add email field to user profile form"

3 points   - Small feature: touches 1-2 components, clear requirements
           Example: "Implement forgot password email flow"

5 points   - Medium feature: crosses multiple systems, some complexity
           Example: "Add two-factor authentication"

8 points   - Complex feature: significant complexity, multiple dependencies
           Example: "Build real-time notification system"

13 points  - Very complex: major feature, high uncertainty
           Example: "Rebuild authentication system"

21 points  - Epic (break down): too large for single sprint
           Example: "Complete mobile app redesign"

見積もりプロセス（プランニングポーカー）

ステップ1：ストーリーの提示（2分）

• PMがストーリーを読み上げる
• 受け入れ基準を明確にする
• エッジケースと依存関係について話し合う

ステップ2：無言で見積もる（1～2分）

• チームメンバーがそれぞれ独立して見積もる
• フィボナッチカードまたはオンラインツールを使う
• この時点では話し合わない

ステップ3：話し合い（3～5分）

• 高い見積もりを出したメンバーが最初に発言する（「なぜ8と見積もったのですか？」）
• 低い見積もりを出したメンバーが次に発言する（「なぜ3と見積もったのですか？」）
• 認識の混乱があればPMが要件を明確にする
• チームで複雑さや不確実性について話し合う

ステップ4：再見積もり（1分）

• 最終ラウンドの見積もりを行う
• 通常は隣り合う1つか2つの数値に収束する
• それでも大きくばらつく場合（1と8など）は、ストーリーをさらに分割する

ステップ5：合意（ストーリーオーナーによる）

• チームの合意が得られたら見積もりを確定する
• 最終的な見積もりを記録する
• ストーリーの再分割が必要な場合はその旨を記録する

見積もりのヒント

過大な見積もりを避ける：

• 同じシステムに取り組む経験豊富なチームメンバーには、1～2ポイントのストーリーを割り当てる
• 不明点は別のストーリーに切り分ける
• 学習時間を理由に見積もりを上乗せしない

過小な見積もりを避ける：

• テストとバグ修正を考慮する（通常20～30％）
• 統合作業とコードレビューを含める
• 正常系だけでなくシステムの複雑さを考慮する
• 「簡単な」項目を楽観的に見積もらない

過小評価されがちなストーリー：

• データベースやデータ移行を伴うもの
• クロスブラウザー対応やマルチプラットフォーム対応
• 統合要件を伴うもの
• サードパーティAPIを利用するもの
• バグ修正（機能開発より複雑です）

見積もりの基準合わせ：

• 過去に完了した類似ストーリーと比較する
• チームのベロシティの推移を使う（スプリントごとに完了した平均ポイント数）
• 見積もりが8ポイントを超える場合は、より小さな単位に分割する
• 見積もり時間を確保する：一般的なチームは2時間で20～30件のストーリーを見積もります

---

スプリント目標の定義

目標設定フレームワーク

効果的なスプリント目標の特徴：

• 明確で具体的（曖昧ではない）
• 1回のスプリントで達成可能（エピックではない）
• 顧客やビジネスの価値を表している（単なるタスクではない）
• チームの意欲を高める（より大きなミッションにつながる）
• 測定可能（完了の明確な定義がある）

スプリント目標テンプレート：

スプリント 12 の目標：「リアルタイムのプロジェクトコラボレーションを実現する」

関連ストーリー：

1. リアルタイムのタスクステータス更新（8 ポイント）
2. アクティビティフィードの表示（5 ポイント）
3. 通知システムの MVP（8 ポイント）
4. WebSocket インフラストラクチャ（5 ポイント）
5. 技術的負債：データベースドライバーのアップグレード（3 ポイント）

対象外（明示的にスコープ外）：

• メール通知との連携（スプリント 13 で予定）
• モバイル通知のサポート（スプリント 13）
• Slack との連携（スプリント 14）

成功基準：

• チームがコミットしたポイントの 80％以上を達成する
• 機能がエラー率 2％未満で本番環境に対応できる
• リアルタイム更新のレイテンシが 200ms 未満

重要な理由：

• チームの会議中心のワークフローを減らします
• 非同期コミュニケーションを改善するための基盤となります
• 定着率が 8％向上すると予測されています

複数チーム間の目標の連携

チームの目標 → スプリント目標 → イニシアチブの目標 → 四半期目標

**四半期目標：**チームのコミュニケーション効率を改善する ├─ イニシアチブ 1：リアルタイムコラボレーション（スプリント 12～13） │ ├─ チーム A の目標：WebSocket インフラストラクチャを構築する │ ├─ チーム B の目標：アクティビティフィードを作成する │ └─ チーム C の目標：通知を実装する ├─ イニシアチブ 2：モバイルアプリ（スプリント 14～15） └─ イニシアチブ 3：高度な分析（スプリント 16）

---

スプリントのキャパシティ計画

チームのキャパシティ計算

スプリント全体のキャパシティ（2 週間）：

• チームの人数：エンジニア 8 人
• エンジニア 1 人あたりの日数：10 日（2 週間）
• 合計人日：80 人日

対応できない時間を差し引く：

• 休暇：2 人 × 2 日 = 4 人日
• カンファレンス／トレーニング：1 人 × 2 日 = 2 人日
• 休日：0 人日
• 利用可能な人日：80 - 6 = 74 人日

オーバーヘッドと会議を差し引く：

• デイリースタンドアップ：15 分 × 10 日 × 8 人 = 2 人日
• スプリント計画：4 時間 = 0.5 人日
• スプリントレビュー／レトロスペクティブ：3 時間 = 0.375 人日
• 1 対 1 のミーティングと事務作業：週 1 時間 × 8 人 = 1.6 人日
• 会議／オーバーヘッドの合計：約 4.5 人日

実質的な開発キャパシティ：74 - 4.5 = 69.5 人日

利用可能なポイント（ベロシティに基づく）：

• 過去のベロシティ：スプリントあたり 120 ポイント（直近 4 スプリントの平均）
• 現在のキャパシティに合わせて調整：120 × (69.5/74) = 目標 112 ポイント

バランスの取れた作業配分

推奨配分：

• 機能ストーリー：85 ポイント（76％）
• バグ修正：15 ポイント（13％）
• 技術的負債：12 ポイント（11％）
• コミット合計：112 ポイント

チーム／重点分野別：

• バックエンド：40 ポイント（35％）
• フロントエンド：35 ポイント（31％）
• モバイル：20 ポイント（18％）
• QA／インフラストラクチャ：17 ポイント（15％）

バッファと予備計画

保守的な見積もり（信頼度 90％）：

• コミットするポイント：85（キャパシティの 75％）
• バッファ：27 ポイント（キャパシティの 25％）
• バッファの用途：バグ、予定外の作業、機会

中程度の見積もり（信頼度 75％）：

• コミットするポイント：112（キャパシティの 100％）
• 前提：完璧な実行、重大なブロッカーがないこと

強気な見積もり（信頼度 50％）：

• コミットするポイント：130 以上（キャパシティの 100％超）
• 結果：スプリントが未完了となり、チームが燃え尽きる（避けてください）

**推奨：**スプリントごとに 85～95 ポイント（キャパシティの 75～85％）をコミットします

---

スプリント計画ミーティングの構成

スプリント計画ミーティングの議題（2週間のスプリントで4時間）

パート1：背景と目標の設定（30分）

「このスプリントで何を達成し、その理由は何ですか？」

• プロダクトマネージャーが最優先項目を提示します
• 優先順位の根拠となる顧客からのフィードバックを共有します
• スプリントのビジネス目標を共有します
• 把握しておくべき依存関係と障害を共有します
• チームが確認のための質問をします

**パート2：ストーリーの精査と見積もり（2時間）

「作業の複雑さはどの程度で、完了とはどのような状態ですか？」

• PMが優先順位順にストーリーを提示します
• エンジニアリングチームが技術的なアプローチを検討します
• プランニングポーカーを使って見積もります（通常、1時間あたり30～40ストーリー）
• 8ポイントを超えるストーリーを分割します
• 依存関係とリスクを特定します

パート3：キャパシティ計画とコミットメント（45分）

「現実的に何を確約できますか？」

• スクラムマスターが利用可能なキャパシティを提示します
• チームが見積もり結果を検討します
• スプリントに含める項目を決定します
• コミットする合計ポイントはキャパシティの75～85％にします
• 実施しないこととその理由を明確に記録します

パート4：スプリント計画とキックオフ（45分）

「どのように実行し、誰が何を担当しますか？」

• 主要項目の技術的なアプローチを検討します
• 各ストーリーのリード担当者を決めます
• ペアプログラミングや知識共有を計画します
• 残っている受け入れ条件を明確にします
• スプリント目標を確認します
• 成功基準と指標を設定します

スプリント計画チェックリスト

• プロダクトマネージャーがバックログに優先順位を付けている
• バックログ項目に受け入れ条件が設定されている
• 8ポイントを超えるストーリーが分割されている
• チームが利用可能なキャパシティを計算している
• 休暇、ミーティング、オーバーヘッドを考慮している
• 上位15～20件のストーリーを見積もっている
• スプリント目標が明確に定義されている
• チームがスプリントへのコミットメントを表明している（必須ではありません）
• 成功指標について合意している
• 依存関係を特定し、対応を計画している
• リスクを明示し、軽減策を計画している
• チーム全員が目標と担当を理解している

---

デイリースタンドアップの運営

スタンドアップの形式（15分、時間厳守）

各メンバーが答える3つの質問：

1. 「昨日、何を達成しましたか？」
2. 「今日は何を達成しますか？」
3. 「どのような障害がありますか？」

例：

• 開発者A：「ユーザー認証のストーリー（3ポイント）を完了しました。今日はパスワードリセットに着手します。障害はありません。」
• 開発者B：「コードレビューと小規模なバグ修正を行いました。今日はパスワードリセットのテストをします。データベーススキーマ待ちです（障害）。」
• QA：「認証フローをテストしました。今日はエッジケースをテストします。パスワードリセットの準備が必要です。」

スタンドアップの進め方：

• 毎日同じ時間に実施します（一貫性）
• 15分の時間枠を守ります（集中を保ちます）
• 立って行います（活力と集中力）
• スプリントのコミットメントについて報告します
• 障害を記録し、フォローアップします

障害の解消

障害の種類：

• 他チームへの依存
• 技術的な障害（要件が不明確、アーキテクチャ上の判断が必要）
• リソース上の障害（コードレビューやインフラストラクチャ待ち）
• 外部要因による障害（サードパーティサービス、顧客からの返答）

障害のエスカレーション：

• スタンドアップで共有します
• スクラムマスターが直ちにフォローアップします
• 可能であれば次のスタンドアップまでに解消します
• 障害が1日を超えて続く場合は、作業を再割り当てします
• チームが作業できない状態を放置しません

---

スプリントの指標と追跡

主要なスプリント指標

ベロシティ（スプリントごとに完了したポイント数）

• 定義：スプリント終了時までに「完了」とマークされたストーリーのポイント数
• 計算方法：完了した項目のストーリーポイントの合計
• 記録対象：直近4～6回のスプリント（推移を確認）
• ベロシティが安定：今後のスプリントを予測するうえで有効です
• ベロシティが上昇：効率が向上している、または作業が容易になっています
• ベロシティが低下：課題や技術的負債の蓄積を示します

バーンダウンチャート（時間経過に伴う残作業）

Sprint Points Remaining
120 |
    | ● (Sprint start)
100 | \●
    |  \●
80  |   \●●
    |    \   ●
60  |     \●
    |      \
40  |       ●\
    |        \●
20  |         \●
    |          \●
0   |___________●●___→
    0  2  4  6  8  10  Days
      (ideal line shown)

• 傾き＝ベロシティ
• 山＝スプリント途中で追加された作業（できる限り避けます）
• 横ばい＝進捗のない日（原因を調査します）
• 10日目までにゼロに向かって下降するのが理想的な推移です

スコープクリープ（スプリント途中で追加・削除されたポイント数）

• 目標：0（スプリント途中の変更なし）
• 許容範囲：コミットしたポイントの5％未満
• 問題あり：コミットしたポイントの10％超（スコープが守られていません）

不具合流出率（スプリント後に発見されたバグ）

• 定義：後続の修正が必要になったストーリーの割合
• 目標：10％未満
• 高い場合：品質に問題があります（テストに投資します）
• 低い場合：QA プロセスが良好です

バーンダウンの読み取り方

健全なスプリント（バーンダウンが計画どおり）：

• 着実に下降している
• スコープの変更が最小限
• スプリント終了までに完了
• チームが予測に自信を持っている

スコープクリープが発生しているスプリント（バーンダウンが徐々に進む）：

• スプリント全体を通して作業が追加されている
• バーンダウンが停滞しているように見える
• チームが過剰にコミットしている、または場当たり的に対応している
• 対応：作業の追加を止め、コミットメントのプロセスを見直します

品質に問題があるスプリント（突然数値が上昇）：

• ブロッカーやバグの発見が急増している
• 想定外の手戻りが見つかった
• レトロスペクティブでの調査が必要
• 対応：コミットする作業を減らし、QA に投資します

ブロックされているスプリント（バーンダウンが横ばい）：

• チームがブロッカーで行き詰まっている
• 依存関係の解消を待っている
• 作業が進んでいない
• 対応：ブロッカーにすぐ対処し、作業を再割り当てします

---

スプリントレビューとレトロスペクティブ

スプリントレビュー（30～45分）

「何を達成し、お客様には何が見えるようになりますか？」

アジェンダ：

1. 背景とスプリントゴールの振り返り（2分）
2. 完了した作業のデモ（20分）
   • 動作する機能を見せます
   • ステージング環境または本番環境でライブデモを行います
   • ステークホルダーからフィードバックを集めます
3. 未完了の作業についての話し合い（5分）
   • なぜ完了できなかったのでしょうか？
   • 次のスプリントに持ち越しますか？
4. フィードバックと質疑応答（10分）
   • お客様とステークホルダーからのフィードバック
   • 機能のリクエスト
   • 今後の作業に向けた方向性のフィードバック

デモのベストプラクティス：

• デモは事前に準備します
• デモ用データではなく、実データを見せます
• エッジケースとエラー処理を見せます
• デモに失敗した場合のバックアッププランを用意します
• 「何を」だけでなく「なぜ」も説明します

スプリントレトロスペクティブ（45～60分）

「何がうまくいきましたか？何を改善できますか？」

主な3つの質問：

1. 「今回のスプリントで何がうまくいきましたか？」
2. 「何を改善できますか？」
3. 「次のスプリントで試すこととして、何に取り組みますか？」

レトロスペクティブの形式：

標準形式（45分）：

• ウォームアップ／アイスブレイク（5分）
• うまくいったことをブレインストーミング（5分）
• 改善点をブレインストーミング（5分）
• 優先度の高い課題に投票（5分）
• 上位2～3件の課題について話し合い（20分）
• アクションとコミットメントを定義（5分）

セイルボート形式（35分）：

Wind (what's moving us forward)
    ▲
    | ✓ Clear requirements
    | ✓ Good pairing
Anchor (what's slowing us)
    | ✗ Slow builds
    | ✗ Meetings interrupting focus
Rocks (what could sink us)
    | ⚠ Tech debt accumulation

スタート・ストップ・コンティニュー形式（30分）：

• スタート：新たに取り入れるプラクティス
• ストップ：中止するプラクティス
• コンティニュー：継続する優れたプラクティス

レトロスペクティブでのアクションとコミットメント

アクション項目は次のようにします：

• 具体的：「API エンドポイントの自動テストを実装する」（「テストを改善する」ではありません）
• 測定可能：「ビルド時間を8分から3分未満に短縮する」（「ビルドを高速化する」ではありません）
• 担当者：特定の個人またはペアを割り当てます
• 期限：スプリント中間のチェックポイントまでに完了します
• 追跡：次回のレトロで確認します

アクションの例：

• 「スプリント中間までにコードオーナーによるレビューを設定する」（担当者：テックリード）
• 「API 統合のパターンを文書化する」（担当者：フロントエンドリード）
• 「毎日午前9時から11時まで集中時間を設ける」（チーム全体のコミットメント）
• 「スタンドアップ中の Slack 使用を制限する」（チームのコミットメント）

レトロスペクティブの指標：

• チームがスプリントごとに3～5件の改善領域を特定する
• 前回のスプリントのアクションの60％以上を完了する
• チームの士気が上昇傾向、または安定している
• ベロシティが安定、または向上している

---

スプリント計画チェックリスト

• バックログの整理と優先順位付けが完了している
• 上位 20 件の見積もりが完了している
• チームのキャパシティを算出している
• 8 ポイントを超えるストーリーを分割している
• スプリント目標を定義し、合意している
• ストーリーをチームメンバーに割り当てている
• 依存関係とブロッカーを特定している
• 成功指標と受け入れ基準が明確になっている
• JIRA／トラッキングシステムにストーリーの説明を記載している
• チームがコミットメントに自信を持っている（感覚：8／10）
• スプリントキックオフミーティングが完了している
• バーンダウンチャートの設定が完了し、使用できる状態になっている
• デイリースタンドアップの時間を設定している
• スプリントレビューとレトロスペクティブを予定している

成果物

1. スプリント計画 - 目標、コミットしたストーリー、キャパシティ計画
2. ストーリーの見積もり - スプリント項目すべての内訳
3. キャパシティ分析 - 利用可能なキャパシティとコミットメントの比較
4. バーンダウンダッシュボード - スプリントの進捗を毎日追跡
5. リスク登録簿 - スプリント中のブロッカーと軽減策
6. チームのコミットメント - 個別の担当と目標
7. 成功指標 - スプリントの成功を測定する方法
8. レトロスペクティブのアクション - 改善事項とコミットメントの記録
9. ベロシティの推移 - 予測に使用する過去のデータ