コンテンツにスキップ
Scrum Knowledge Graph

スプリントプランニング (Sprint Planning)

概要

Section titled “概要”

スプリントプランニングは、各反復サイクルの起点においてチームや関係者が協力して実施するタイムボックス化された計画イベントである。プロダクトバックログから優先項目を引き出し、提供価値をステークホルダーの期待と整合させつつ、明確なスプリントゴールを合意して作業項目をスプリントバックログへと確定する。アジャイルのライフサイクルにおいて最も意思決定研究が集中する領域であり、プランニングポーカーや最適化アルゴリズム等の支援技術を活用し、チームの社会的相互作用と技術的制約が交差する協調メカニズムとしても機能する。自律性や集中を促して持続可能な作業環境を形成し、フロー指標の活用や大規模環境での同期など幅広く展開される一方、自律性の制約やゴール未設定といったアンチパターンへの対処が求められる。

詳細

Section titled “詳細”
  • 実施タイミングと役割の差異: 多くの標準的な定義[1][2][3][4][5][6][7][8]では、各スプリントの開始時（初日）に実施されるスプリントの起点と位置づけられる。短い反復サイクル（1〜5週間）の開始時にチームメンバーと関係者が次回の反復で実現する内容について合意を形成する場としても位置づけられる[9]。一方で、スプリント期間の終わりにプランニング会議を実施して次のバックログを作成・調整すると定義し、開発者が短期間で取り組むべきタスクを整理・明確化する役割を強調する見解もある[10]。
  • 3トピック構成: スプリントの起点として「なぜ（スプリントの価値）」「何を（実施する機能・作業の選択）」「どのように（デリバリーやタスクの実行計画）」という3つのトピックから計画を構築する[3][4][5]。プロダクトオーナーが最優先項目や戦略、価値あるプロダクトの目的を提示し、チーム全体で協力してスプリントの唯一の目的であるスプリントゴールを定義・確定する[3][4][5]。さらに、選択したプロダクトバックログアイテムを完成の定義を満たすインクリメントへ変えるため、1日以下のタスクに分解するなどの具体的かつ詳細な実行計画を開発者が策定し、スプリントバックログを構築する[3][4][5]。
  • 後半のパート（How）では、選択した項目を出荷可能な「完成」したインクリメントに変えるための具体的な詳細タスク（1日未満の作業単位等）へ開発者（開発チーム）が洗い出し・分解し、スプリントバックログを作成・構築する[1][11][12][2][13][14]。この際、チーム（開発チーム）が次のスプリントで実行可能・受け入れ可能な作業量を自律的に判断し、選択に責任を持つ[1][11][12][14]。
  • 開発者の自律性と裁量権: 作業の進め方や具体的な実行計画の策定は開発者の裁量に委ねられており、他者から指示されたり一方的に割り当てられたりすることはない[4]。
  • リファインメントの影響: 事前に十分なバックログリファインメントが行われている場合、スプリントプランニングにおける作業選択と計画の策定が迅速かつスムーズに進行する[6]。
  • 優先項目の選択とステークホルダー整合: プロダクトバックログから優先順位の高いアイテムを引き出し、スプリント内での提供価値をステークホルダーの期待と整合させるプロセスとしても機能する[15]。
  • その他の文献・手法における定義: 以下のような多様な記述が存在する。（1）プロダクトオーナーが完成させる機能を提示した上で実装タスクを定義するプロセス[8]。（2）プロダクトロードマップやプロダクトバックログの優先順位をレビューし、プロダクトオーナー、スクラムマスター、開発者（開発チーム）が参加してバックログ（BDDのユーザーストーリーやシナリオ等）を選択・実行可能なタスクへ分解し、工数を見積もってメンバーへ割り当て、スプリントバックログを決定・確定するプロセス[6][16][7]。（3）プロダクトバックログの上位項目を抽出しアクティビティレベルでのタスク分解により設計・開発・テストのスケジュールを立てるプロセス[17]。（4）プロダクトオーナーやステークホルダーと協力して優先順位付けされたセキュリティ要件などの課題をスプリントの作業計画に統合するプロセス[10]。（5）チームが各タスクに必要な作業量を見積もり、スケジュールを遵守するためにタスクの範囲を小さく分割して中間目標を定期的に定義・評価し、その評価に基づいて完了させる作業量を計画・決定するプロセス[9]。

スプリントプランニングは単なる計画策定にとどまらず、スクラムチーム全体の集中を高め、自律的な作業の選択・計画を通じてスプリント内で達成する成果やスプリントゴールに対するチーム全体の強いコミットメントを生み出す重要な場として機能する[4][17][6]。スプリント計画において明確なスプリントゴールを設定することは、チームの共有目標の確立やチームの有効性に寄与する[15]。さらに、優先順位を明確化してコミットすることで、反復期間中における作業範囲の頻繁な変更や割り込みを防ぎ、集中できる保護された作業空間を確立して過負荷を回避し、持続可能なペースを維持する基盤を整える[9]。

ソフトウェア開発チームに限らず、ビジネスチームがアジャイルな働き方を習得し実践する初期段階において導入される典型的なスクラムプラクティスの一つとしても位置づけられる[18]。

スプリントプランニングは単なるタスク計画の場にとどまらず、チーム内のコミュニケーションと調整を円滑にする重要なアジャイルプラクティスとして機能する[19]。

  • アクティブコミュニケーションの達成: 同拠点（コロケーション）開発において、チームメンバー間の会話をインフォーマルな対話へと転換させ、アクティブコミュニケーションを達成するための契機となる[19]。
  • チーム連携の強化: 活発なコミュニケーションを通じて、チーム全体の相互理解と連携を深める要素として貢献する[19]。
  • リモート環境における適用性: リモートワーク環境においても、タスクの追跡や進捗調整の観点から比較的効率的に機能しやすいとされる[8]。

スプリントプランニングにおける意思決定には、実行フェーズと比較して独自の柔軟性や裁量が存在し、多彩な手法やモデルが適用される[20][21]。

  • 多様な意思決定スタイル: 実行フェーズと比較して、計画フェーズでは独裁的・協議的・グループ合意といった多様な意思決定スタイルが許容されており、全体としてチームの自律性の幅が広い[20]。
  • 参加者の招待: スクラム、Nexus、LeSS、SAFeなどの各種フレームワークでは、必要に応じて外部メンバー（他チームの代表者など）を招待して意見を求める決定をチーム全体の合意によって行う[20]。
  • ワークフローの決定: すべての大規模フレームワークでチームに一定の自由度が認められており、SpotifyモデルやSAFeではスクラムかカンバンかの選択自体もチームレベルで決定可能である[20]。
  • ライフサイクルにおける位置づけと意思決定モデル: スプリントプランニングは、アジャイルソフトウェアエンジニアリングのライフサイクル領域の中で最も意思決定の研究が集中している領域（PLA）であり、分析型（ANA）やハイブリッド型（HYB）などの多様な意思決定モデルが適用されている[21]。
  • 公式なトレードオフ議論の場: プロダクトオーナー、スクラムマスター、開発者が明確な基準、トレードオフ、およびステークホルダーからのフィードバックを公式に議論し調整する場として機能する[21]。
  • 具体的な意思決定支援技術: プランニングポーカー、整数計画法によるストーリー選択アルゴリズム、ペアワイズ比較（AHP/サティスケール）、速度ベースの予測など、多様な支援技術や数理的アプローチが計画策定に用いられる[21]。
  • 社会技術システムとしての協調メカニズム: チームによる議論という社会的相互作用と、タスク間の依存性やシステム制約という技術的制約が交差する、形式的な協調メカニズム（社会技術システム）を構成している[21]。

フローに基づくスプリントプランニングでは、プロセスの流れや定量的なパフォーマンス指標に基づいた手法を用いて計画を立案する[22]。

  • キャパシティの把握: 過去のスループットデータを客観的な参照指標として活用し、スクラムチームの現実的なキャパシティを正確に把握する[22]。
  • スプリントバックログの構築: フローベースのスプリントプランニングでは、流れの指標を使いながらスプリントバックログを構築する[22]。
  • 共有スプリント計画（Shared Sprint Planning）の導入: LeSSやNexusなどの大規模アプローチでは、複数チームが足並みを揃え、全体としての整合性を保つために共有されたスプリント計画プロセスが採用される[15]。
  • アジャイルリリーストレイン（ART）における同期と共同計画: アジャイルリリーストレイン（ART）などの大規模環境では、複数チームや関連機能が足並みを揃えて作業を同期するための共同計画イベントとしても活用される[18]。
  • 複数チームによる統合開発環境（Nexus）: Nexusスプリントプランニングでは、プロダクトオーナーと各スクラムチームの代表者が集まり、全体の作業と活動を調整することを目的とする[23]。目的となる全体の「Nexusスプリントゴール」を決定した上で、各スクラムチームがそれに沿ったそれぞれのスプリントゴールを保持・調整し、チーム間の依存関係を明示化した「Nexusスプリントバックログ」および各チームの「スプリントバックログ」を確定する[23]。また、事前のクロスチームリファインメントを実施しておくことで、計画時に新たな依存関係が発覚するリスクを最小限に抑える仕組みを備える[23]。
  • スケールされた組織環境（Scrum@Scale）: スプリントゴールやバックログアイテムを明確化するとともに、プロダクトオーナーチームが「何がデリバリーされるか（What）」についての洞察を得る一方、スクラムマスターがチームのキャパシティや技術的能力についての評価・洞察（How）を得ることで、両者の整合性を図る[24]。複数チーム環境において、作業範囲やチーム間の依存関係を事前調整する重要な機会として機能し、計画の実現可能性を確保する[24]。
  • 大規模化に伴う自律性の制約: 大規模アジャイルフレームワークにおいては、チームレベルの計画に先立ち、チーム・オブ・チームズレベルでの計画イベント（SAFeのPI PlanningやNexusの計画イベントなど）が実施され、事前の依存関係解消やアイテム割り当てによってチームの自律性が制約される傾向がある[20]。Nexusではチーム集合レベルでNexusスプリントバックログやゴールを策定するため個別チームの自律性が低下し、SAFeではPI Planningによってバックログアイテムをストーリーに分解した上で、目標に対するビジネスオーナーの合意を仰ぐプロセスが存在する[20]。
  • 計画の不整合とチーム間連携の課題: 大規模開発においてアジャイルチームが他チームとの連携を欠いた状態で次期スプリントの計画を立てると、計画のずれが生じ、機能納品の一貫性が損なわれる原因となる[^slr-challenges-agile-scrum-2025]。チーム間での事前計画や情報共有（コミュニケーション）の不足は依存関係の特定を遅らせ、開発段階で深刻な手戻りを引き起こす[^slr-challenges-agile-scrum-2025]。そのため、個別チームの計画に閉じることなく、フロントエンドからバックエンドにわたるエンドツーエンドの開発・統合やシステム全体にわたる機能の流れを意識した計画策定が不可欠となる[^slr-challenges-agile-scrum-2025]。

単一チームの成果物としては、スクラムチームで策定・確定するスプリントゴール、選択されたプロダクトバックログアイテム（BDDストーリーやシナリオ、優先順位付けされたセキュリティ要件を含む）、およびそれを届けるための実行計画（タスク分解・工数見積もり・割り当てやアクティビティレベルのスケジューリング等）を合わせた、スプリント全体の作業ガイドとなる「スプリントバックログ」が作成・確定される[1][11][2][3][16][17][10][7][6]。また複数チームの統合環境（Nexus）においては、プロダクトゴールに沿った「Nexusスプリントゴール」と各チームのスプリントゴール、およびチーム間の依存関係を明示化・調整した「Nexusスプリントバックログ」と各チームの「スプリントバックログ」が作成・確定される[23]。

1か月間（4週間）のスプリントにおけるタイムボックスは最大で8時間（8時間を上限）として実施される[1][11][2][3][4][5][16]。また、スプリント期間がより短い場合は、比例してタイムボックスも短縮して開催されることが規定・明記されている[12][4][16]。

実際の開発現場では、チームやプロジェクトの文脈に応じた多様なテイラリング（カスタマイズ）の実施が見られる[25]。

  • 複数回のミーティング開催・事前検討: オンショア・オフショアチーム間での情報共有や分散チーム・異なる役割間の調整等を目的として、事前プランニングミーティングの導入やスプリント内での複数回（例: 2回）の分割開催が行われることも見られる[25]。
  • 構成要素やプロセスの制限: プロダクトバックログを使用せずスプリントバックログのみを主要な機能ソースとして使用したり、プロダクトバックログアイテム（ストーリー）の作業量を見積もらなかったりする運用が見られる[25]。
  • スプリントゴールの欠落: 明確なスプリントゴールを定義せずに計画を進める運用が見られる[25]。
  • テイラリングの影響とリスク: ストーリーの見積もり省略や明確なスプリントゴールの非設定など、過度・不適切なテイラリングは、スプリント目標の不全、重要機能の実装失敗、計画の無秩序化や非効率なミーティングの誘発といった高いリスクをもたらす[25]。

スプリント計画では、スプリントを通じて達成すべきスプリントゴールの確立と、作業項目の選定・分割が行われる[26]。しかし、開発組織における実態調査では以下のようなアンチパターンの頻発や常態化が報告されている[26]。

  • スプリントゴールの設定不備: 「スプリントゴールが会議中に設定されない、または最後に設定される」という反パターンの重み付けスコアは53.57%（満点168に対する割合で、組織の割合ではない）で4位である[26]。著者らはスクラムの原則に反するものと見なしている[26]。
  • 詳細化・分割の分析不足: 「ユーザーストーリーが十分に詳細化されていない」（重み付けスコア58.93%）や「大きなユーザーストーリーを小さなものに分割しない」（同38.10%）など、計画段階での分析不足に関する項目が上位にある（満点168に対する割合で、組織の割合ではない）[26]。
  • 会議運営の不備と計画不良による作業追加: スプリント計画会議に明確なアジェンダが存在しない問題（重み付けスコア30.36%）と、「スプリント中にアイテムを追加する」反パターン（同42.86%）が調査されている（満点168に対する割合）[26]。

スプリントプランニングでは次のスプリントで何を行うかを議論し、1つのスプリント内でタスクを完了させるために、プロジェクトは小さなタスクに分割される[27]。

大規模アジャイル環境においては、共有アラインメント・アーティファクト等の横断的な合意モデルを活用することで、組織境界を越えた整合性のあるスプリント計画の立案が可能となる[28]。

リモートワークへのスクラム実践の適応を扱ったデルファイ調査（予備的）では、スプリントプランニングの前にバックログのリファインメントに特化したプレプランニングを置くことで、長時間のバーチャルプランニングセッションによる疲労を抑え、プランニングをより効率的にできるとされた[29]。

Ericssonの大規模アジャイル開発組織の事例では、スプリントプランニングは、割り当てられたチームの開発状況確認と、各チームによるユーザーストーリーの開発タスクへの分割という2部構成で実施される[30]。37 回のレトロを追った事例研究では、見積りの問題に最も多くの是正アクションが策定されたが、繰り返される議論と多数の是正アクションにもかかわらず、見積り精度は向上しなかった[31]。大規模なアジャイル ERP 変革プログラム 1 件のケーススタディでは、各スプリントプランニングの成果は、更新されたスプリントバックログとウェーブ計画だった[32]。

安全重視のソフトウェア向けの Scrum for Safety（S4S）のスプリントプランニングでは、チームメンバーは CENELEC EN 50128 の V 字モデルと同じ考え方で作業を分担し、設計とテストの両方を担当する人を置かない[33]。

製造業 1 社の製品開発（期間 2〜5 年）の事例研究では、2〜5 年全体を見積もるより、4〜6 週間のスパンで工数・作業量・相互依存を見積もる方が容易だったため、スプリントプランニングが工数の見積もりと期間の管理を助けた[34]。

スプリントプランニングは、スプリント開始時にプロダクトバックログアイテムからタスクを選定してスプリントバックログを作成し、スプリントのゴールを定義するイベントである[35]。

STEM-EFにおいてスプリントプランニングは、リファインメント、スプリントゴールの定義、スプリント計画の調整、規模見積もりの4つの中核活動に分解され、心理的安全性や対人関係スキルが発揮される重要な機会として位置づけられている[36]。

スプリントプランニングは、選択されたストーリーの実現可能性を事前に検証し、作業に伴う不確実性や前提条件を特定して開発着手の合意を形成する機会である[37]。

機械学習プロジェクトでは、実験的な性質やタスク間の強い相互依存性により、タイムボックス化されたスプリントプランニングにおいて計画立案や工数見積もりが困難になる[38]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Scrum Core Event Planning Decision Making Events
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

脚注

Section titled “脚注”

  1. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4 ↩5

  2. Scrum Guide 2013 — 「スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリント レトロスペクティブで構成される。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  3. Scrum Guide 2020 — 「スプリントプランニングはスプリントの起点であり、ここではスプリントで実行する作業の計 画を立てる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Scrum Guide Expansion Pack — 「- スプリントプランニング:スプリントゴールを定義し、作業計画を立てる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  5. Scrum Guide (LeSS Version) — 「スプリントプランニングはスプリントで実施される仕事を明確にする場となる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  6. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  7. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「スプリントプランニングは、各スプリントの開始時に行われる協調的なミーティングであり、プロダクトオーナー、スクラムマスター、および開発チームが参加する。」（原文: “Sprint Planning is a collaborative meeting that occurs at the beginning of each Sprint and involves the Product Owner, Scrum Master, and the Development Team.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  8. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  9. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  10. Agile Software Development with Secure and Scrum-Centric Approach（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  11. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4

  12. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3

  13. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩

  14. Scrum Guide 2017 — 「スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレト ロスペクティブで構成される。」（ライセンス: CC BY-SA 4.0） ↩ ↩2

  15. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  16. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「- a) スプリントプランニング: そのスプリントで実行する作業を計画するためにSMとSTが参加するミーティングであり、1ヶ月のスプリントで最大8時間、より短いスプリントではそれ以下となります。」（原文: “a) Sprint Planning is a meeting involving SM and ST for planning the work to be performed in that sprint, which can last a maximum of 8 h for a 1-month sprint or less for shorter sprints;”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  17. Scrum: An Agile Software Development Process and Metrics — 「スクラムでは、各スプリントに構造を提供する4つのセレモニー（イベント）を組織します：スプリントプランニング、デイリースタンドアップ、スプリントデモ、スプリントレトロスペクティブです。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  18. Dependencies of Agile Teams – An Analysis of the Scaled Agile Framework（ライセンス: CC BY 4.0） ↩ ↩2

  19. An Empirical Investigation of Geographically Distributed Agile Development: The Agile Enterprise Architecture is a Communication Enabler（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  20. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  21. Decision-Making in Agile Software Engineering: A Systematic Literature Review of Models, Methods, Actors and Lifecycle Contexts — 「バックログリファインメントやスプリントプランニングなどの計画・優先順位付けタスクは、通常、意思決定基準、トレードオフ、ステークホルダーからのインプットが明示的に議論される、より形式化された場で行われる。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  22. Kanban Guide for Scrum Teams 2021 — 「フローベースのスプリントプランニングでは、流れの指標を使いながらスプリントバッ クログを構築する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3

  23. Nexus Guide — 「Nexus スプリントプランニングの目的は、 1 つのスプリントにおける Nexus のすべてのスクラム チームの活動を調整することである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  24. Scrum@Scale Guide — 「スケールされたスプリントプランニングは、プロダクトオーナーチームとスクラムマスターが行う。」（ライセンス: CC BY-SA 4.0） ↩ ↩2

  25. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「スプリントプランニング（SP）とスプリントレトロスペクティブは、3番目に最もよくテーラリングされるスクラムのプラクティスである。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  26. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  27. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「1つのスプリント内でタスクを完了させるために、プロジェクトは小さなタスクに分割されます。」（訳）（ライセンス: CC BY 4.0） ↩

  28. Building Shared Alignment for Agile at Scale: A Tool-Supported Method for Cross-Stakeholder Process Synthesis — 「これにより、暗黙知を表面化させて共通の理解を構築するための構造化された方法が得られ、そうでなければ暗黙のままであったであろう視点を可視化することで、バックログリファインメントやスプリントプランニングといったアジャイルのプラクティスが強化される。」（訳）（ライセンス: CC BY 4.0） ↩

  29. A Delphi Study on the Adaptation of SCRUM Practices to Remote Work — 「このプラクティスは、優先順位を明確にしバックログへの理解を深めることで、長時間のバーチャルプランニングセッションによる疲労を最小限に抑え、プランニングをより効率的なものにする。」（訳）（ライセンス: CC BY 4.0） ↩

  30. Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson — 「スプリントプランニングは2部構成で行われる。第1部は、そのフィーチャーに割り当てられたチームの開発状況確認会議のようなものである。第2部は各チームが個別に実施する。第2部では、チームはユーザーストーリーを具体的な開発タスクに分割し、それらがチームのバックログに追加される。」（原文: “Sprint planning is conducted in two parts. The first part is akin to a development status meeting of the teams assigned to the feature. Each team conducts the second part individually. In the second part, the teams split their user stories into concrete development tasks which are then added to the team’s backlog.”）（訳）（ライセンス: CC BY 4.0） ↩

  31. Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives — 「チームメンバーは見積りの問題に対して最も多くの是正処置を策定したが、繰り返される議論と多数の是正処置にもかかわらず、見積り精度は向上しなかった。」（訳）（ライセンス: CC BY 4.0） ↩

  32. Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program — 「各スプリントプランニングの成果は、更新されたスプリントバックログとウェーブ計画である。」（訳）（ライセンス: CC BY 4.0） ↩

  33. Scrum for safety: an agile methodology for safety-critical software systems — 「誰も設計活動とテスト活動の双方を担当することはできない。」（訳）（ライセンス: CC BY 4.0） ↩

  34. The interrelationship between the agile approach and project complexity in product development — 「チームメンバーにとって、製品開発プロジェクト全体の2〜5年という期間にわたって見積もるよりも、4〜6週間のスパンでタスクに関する工数を時間、作業量、相互依存関係の観点から見積もる方が容易であったため」（訳）（ライセンス: CC BY 4.0） ↩

  35. Scrum: A Systematic Literature Review — 「スプリントプランニングでは、プロダクトバックログアイテムからタスクと重み付けが選択される。」（原文: “In the sprint planning, tasks and weights are chosen from Product backlog items.”）（訳）（ライセンス: CC BY 4.0） ↩

  36. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「各項目は、意図された行動の焦点に基づき、スクラムイベント（スプリントプランニング、デイリースクラム、スプリントレビュー、またはスプリントレトロスペクティブ）に明示的にマッピングされた。」（原文: “Each item was explicitly mapped to a Scrum event—Sprint Planning, Daily Scrum, Sprint Review, or Sprint Retrospective—based on its intended behavioral focus.”）（訳）（ライセンス: CC BY 4.0） ↩

  37. Collaboration and Uncertainty Management in Agile Software Development: A Systematic Integrative Review and Literature-Based Positioning of CDM — 「スプリントプランニングでは、選択されたストーリーが十分に理解され実現可能であることを検証できます。」（訳）（ライセンス: CC BY 4.0） ↩

  38. Agile Management for Machine Learning: A Systematic Mapping Study — 「第1に、「スプリントプランニングと見積り（Sprint Planning & Effort Estimation）」。」（訳）（ライセンス: CC BY 4.0） ↩