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

スプリントバックログ (Sprint Backlog)

概要

Section titled “概要”

スプリントバックログは、スクラムにおける中核的な成果物であり、スプリントゴール、選択されたプロダクトバックログ項目、およびインクリメント提供に向けた具体的作業計画で構成される。機能開発タスクのみならず、アーキテクチャの不確実性や仮説に対処する技術タスクも含まれ、デジタルカンバンボード等を介して可視化される。チームのキャパシティに基づき作業の投入を制御する下流キューとしても機能し、開発者の自己管理と協働を促す。日々の進捗や学習に応じてリアルタイムに更新される創発的な性質を持ち、知識活用とフィードバックを加速させる基盤となる。大規模開発や各種フレームワークでは、階層構造や責任主体に差異が存在し、多様な実践やテイラリングがなされている。

詳細

Section titled “詳細”
  • 構成と基本定義：スクラムフレームワークにおける主要アーティファクトであり[1]、プロダクトバックログやバーンダウンチャートとともにプロセスを支える中核アーティファクトとして位置づけられる[2]。スプリント内での作業連携と自己管理を支える中心的な成果物として機能し[3]、開発すべき機能や詳細タスクを明確にすることでチームの自己組織化を促す[2]。2009年版の定義では、選択された項目を「完了」のインクリメントへ変えるために必要なタスク一覧として作成されるとされた[4]。2020年版では「開発者のための計画」と明確に位置づけられ、スプリントゴール（なぜ）、選択されたプロダクトバックログ項目（何を）、およびインクリメントを届けるための具体的計画（どのように）という3つの要素で構成される[5][6][7][8][9][10][3]。なお、2017年版では前回のレトロスペクティブで特定された優先度の高いプロセス改善策が少なくとも1つ含まれると定義されていた[8]。その他、プロダクト開発者による開発者のための計画として整理する立場[11]や、大規模な適用において共通プロダクトバックログから引き出されたアイテムやチーム独自のタスクによって構成されるとする立場もある[12]。計画時に最初からすべての作業を網羅する必要はなく、作業を開始するのに十分な要素が含まれていればよいとされる[5][11]。タスクは1日未満で実施可能な粒度へ分解されることが多く[4]、特定のスプリント期間中に実装・完了させるべき要求や詳細タスクのリストとして広く説明されている[9][13][14][15][1][10]。さらに、デイリースクラムで進捗を明確に確認・把握できる詳細度を持つことが推奨される[16]。
  • 作成・所有権および責任主体の変遷と差異：
    • スクラムガイドおよび関連ガイドの変遷：2009年版および2010年版ではチーム（開発チーム）が所有権を持ち、スプリント中に内容や作業見積もりを変更できるのもチームのみとされた[4][17][6][7][8]。2020年版では開発者のための計画と再整理され、開発者自身の自主的な裁量により管理される[5]。スプリントプランニングにて決定され、開発者によって所有・管理されるとする分析も存在する[3]。また、プロダクト開発者による開発者のための計画と提示する見解もある[11]。
    • その他アプローチ：スプリントプランニングにおいてスクラムチームが作成すると定義する立場[14]、チームによって作成され、チーム自身のための作業計画として所有・管理されるとする立場[16]、各スクラムチームのプロダクトオーナーおよびチームがビジネス目標に応じた構成と優先順位付けに責任を持つとする立場もある[12]。多くのフレームワークでは開発者またはスクラムチーム全体で定義されるのに対し、Scrum@Scaleでは各プロダクトオーナーが個々のスプリントバックログを単独で担当・定義するという分析も存在する[18]。
  • 確約（コミットメント）の定義における差異：
    • 2020年版スクラムガイドにおける規定：スプリントバックログに含まれる確約（コミットメント）はスプリントゴールであり[5][11]、目的達成に向けた計画変更の柔軟性を担保するものとされる。
    • 関連フレームワークにおける規定：Nexusでの確約（コミットメント）はNexusスプリントゴールとして提示されている[19]。
    • 従来の定義：スクラムチームがスプリント中に完了できると信じ、作業項目および詳細なタスクに対してコミットするという観点から定義される場合もある[13]。
  • 構築手法・フローおよびアプローチ（セキュリティ・BDD・仮説エンジニアリング等）：
    • フローベースの構築とワークフロー：フローベースのスプリントプランニングにおいては、チームの過去のスループットデータを考慮してチームのキャパシティに合わせたバックログが構築される[20]。なお、チームが定義する「ワークフロー」の範囲は、スプリントバックログ自体の範囲を超える外部の流れを含む場合がある[20]。
    • セキュリティ重視のアプローチ：セキュリティに関する課題や対策を考慮して精緻化（リファイン）され、バックログの構成やタスク定義が行われるとともに、日々の開発作業や討論、スプリント期間中のタスク管理の基準として活用される手法が存在する[15]。
    • BDD（ビヘイビア駆動開発）との連携：BDDに基づくアプローチでは、選択されたユーザーストーリーおよびシナリオと、それに対応する受入テストや実装タスクによって構成される[13]。
    • 仮説エンジニアリングとアーキテクチャの不確実性管理：各スプリントの開始時のスプリントプランニングで、高い不確実性や影響度を持つ仮説に対処するための技術計画タスク（アーキテクチャタスク）を機能タスクとともにバックログ上で優先順位付けする実践も報告されている[21]。
    • 安全重視のソフトウェア向けの手法におけるスプリントプランニングの範囲：Scrum for Safety（S4S）では、スプリントプランニングの範囲はスクラムと同様で、明確で実現可能な目標（スプリントゴール）から始めて、最も重要なストーリー群（スプリントバックログ）を選ぶこととされる[22]。
  • キューイング構造と投入制御：システム安定性の観点からは、二重のキューイング構造の一部として分析される[23]。スプリントプランニングにおいて、チームが利用可能なキャパシティに基づいてプロダクトバックログから選択したアイテム群によって構成される下流キューとして機能する[23]。上流キューであるプロダクトバックログからスプリントバックログへのアイテムの移行はバッチ処理の性質を持ち、チームの処理能力に合わせた作業の投入制御を可能にする[23]。
  • 創発性とリアルタイムな更新（透明性と適応およびフィードバック）：日々の進捗や作業を通じて得られた学習をもとに、新しい作業の追加や完了作業の反映、不要になったタスクの削除がリアルタイムに行われる創発的性質を持つ[4][6][7][8][5][11][12][16][3]。この変更を行えるのは各版における所有主体（チーム／開発チーム [4][6][7][8]、または開発者 [5][3]）の自主的な裁量による。進捗を検査し適応できるよう学習をふまえて随時更新されるほか[19]、スプリントレビューやエンドユーザーからのテスト結果、フィードバックに応じて次期スプリントバックログへ新たな改修要求や調整がすぐさま組み込まれ、適応的な改善が行われる実践も存在する[10]。
  • 検査と進捗の追跡（監視）：残作業時間を毎日算出し、進捗の把握やバーンダウンチャートなどのツールを用いた日々の残作業量の監視・管理に活用される[4][9][14]。また、カンバンボードなどを活用して開発タスクや研究タスクの進捗状況を可視化・追跡する手法も用いられ[10]、デジタルカンバンボードを通じてスプリント期間中の作業進行状況が可視化される実践も存在する[21]。デイリースクラムなどを通じて進捗状況やタスクの変更が随時透明化・確認・検査・更新され、不確実性に対する継続的な調整が行われるとともに、作業の進捗を理解・把握できるレベルの十分詳細な計画として維持される[7][5][11][16][13][1]。少なくともデイリースクラムで残作業を合計・追跡・検査し、スプリントゴール達成に向けた進捗を管理するために使用される[7][8]。
  • 大規模開発および分散・リモート環境における構造・課題と運用：
    • Nexus：複数チームのアイテムとNexusスプリントゴールを組み合わせた「Nexusスプリントバックログ」が運用される[19]。これはスプリント期間中のチーム間の依存関係や作業の流れを強調・透明化するために使用され、Nexusデイリースクラムを通じて進捗を検査し適応できるよう学習に合わせて随時更新される[19]。また、各チームの代表者とプロダクトオーナーがNexusスプリントバックログと個別チームのスプリントバックログの双方を定義し、全スクラムチームによって更新される2層構造を持つとも整理される[18]。
    • Scrum@Scale：各スクラムチームのプロダクトオーナーおよびチームがビジネス目標に即して全体の構成や優先順位付けに責任を持ち、共通プロダクトバックログやチーム固有のタスクを組み合わせて運用される[12]。
    • スケーリングフレームワークにおける自律調整と意思決定：スプリント中のバックログ調整に関して、SAFeではスプリント期間中にチームが自律的にバックログを調整できることが明示されているのに対し、多くのスケーリングフレームワークではチームレベルでのスプリント中のバックログ調整を明示せず上位レベルで扱う傾向が指摘されている[18]。
    • 分散・リモート環境とChainAgile：リモート環境での作業管理の中心となる一方で[1]、分散環境におけるバックログの合意形成と透明性を確保するため、スマートコントラクトとして実行・管理するアプローチが存在する[24]。このフレームワークでは、要件抽出および優先順位付けの成果として開発チームがバックログを所有し、スプリント内で実施するタスクや時間を設定してイーサリアムなどのブロックチェーンにデプロイする[24]。バックログの状態移行が不変データとして記録されるため、リモートチーム間での進捗追跡や管理が容易になる[24]。
    • 依存関係の調整課題：複数チーム環境においては、自チームのスプリントバックログの内容が他チームの作業順序や手渡しタイミングと整合しているかを意識・調整する必要があり、この調整が欠落するとプロジェクト全体のデリバリー計画に支障をきたす課題が生じる[2]。
  • 実務におけるテイラリング（選択的調整）の動向と課題：プロダクトバックログと比較すると報告事例は少ないものの、現場の文脈に応じた多様な調整が行われている[25]。単一の人物のみが作成に関与するプロセスの簡略化や、複数のバックログの維持・運用、外部ツールやアーティファクトとの併用などの手法が見られる[25]。しかし、バックログ作成における協働の欠如は、計画の不透明化やスプリントゴールの共有不足といった課題を引き起こす要因となる[25]。

在宅勤務でスクラムを行った 12 人へのインタビューでは、バックログがデジタル形式であることで、スプリントの状況・各メンバーの作業・対応可能な人を素早く確認しにくいと感じる人がいた[26]。

スプリントバックログは、特定のスプリントサイクルにおいてスクラムチームが実行するすべてのタスクと達成すべきゴールを保持する作成物である[27]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Sprint Backlog Scrum Artifact
  • カテゴリー: Scrum Core

オントロジー上の位置

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

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • E6 [警告] (IntendedScrumDevelopmentTask): タスクに見積もり(TaskEstimation)が存在しません。文献(Özkan & Özcan-Top, 2022)によれば、見積もりを省略するテイラリングは、非現実的なスプリントゴールを招き、結果としてメンバーのモチベーション低下を引き起こすアンチパターンです。親のユーザーストーリー側に見積もりが存在する場合は、欠落ではなくストーリー単位で見積もる運用による粒度の差である可能性があります。見積もりはタスクから srom:hasEstimation（https://kemsakurai.github.io/sro-metrics#）で結びつけてください。sro:has はスプリント→スプリントバックログ専用のプロパティであり、見積もりの紐付けには使えません。
  • R1 (PerformedScrumDevelopmentTask): このタスクが生成した成果物は、実行されたスプリントのスプリントバックログに含まれるユーザーストーリーを具現化していません。タスクとユーザーストーリーの紐付けを確認してください。
  • R2 (PerformedScrumDevelopmentTask): このタスクはユーザーストーリーを満たすために実行されましたが、そのユーザーストーリー向けにスプリントバックログで計画された「意図されたタスク」に起因していません。
  • S5 (SprintBacklog): スプリントバックログは、ユーザーストーリーを満たすための「意図されたタスク（Intended Task）」を少なくとも1つ以上特定・包含しなければなりません。
  • S6 (IntendedScrumDevelopmentTask): 意図されたタスクは、必ず特定のユーザーストーリーを達成するために計画されていなければなりません。紐づくユーザーストーリーが存在しません。

脚注

Section titled “脚注”

  1. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered — 「スクラムは、プロダクトバックログやスプリントバックログといった主要な作成物（アーティファクト）と、デイリースクラム、スプリント計画（Sprint Planning）、スプリントレビュー（Sprint Review）、スプリントレトロスペクティブ（Sprint Retrospective）などの定期的なイベントで構成されています。」（原文: “Scrum consists of key artifacts such as the Product Backlog and Sprint Backlog, as well as regular ceremonies including the Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  2. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

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

  5. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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

  7. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  8. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Scrum: An Agile Software Development Process and Metrics — 「スプリントバックログでは、タスクがアクティビティレベルに分解され、それらすべてのアクティビティのスケジューリングが行われ、それらすべての機能の要件定義、設計、コーディング、テストが継続的に実行されます。」（原文: “In the Sprint Backlog, the task breaks down into the activity level and then schedule all those activities and then keep on doing those requirements, design, coding, and testing of all those features.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  10. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「スプリントバックログやバーンダウンチャートは、研究活動（例：インタビューのテーマ別コーディングなど）がコーディングタスクとは異なる進捗をたどることを認識した上で、柔軟に使用されました。」（原文: “Sprint backlogs and burndown charts were used flexibly, acknowledging that research activities (e.g., thematic coding of interviews) progress differently from coding tasks.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  11. Scrum Guide Expansion Pack — 「スプリントバックログは作成物の一つである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  12. Scrum@Scale Guide — 「各チームのプロダクトオーナーは、自チームのスプリントバックログの構成と優先順位付けに責任を持ち、ビジネス目標の達成に必要な場合は、自身の裁量で、共通バックログからアイテムを引き出したり、独立したバックログアイテムを生成することができる。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  13. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  14. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「スプリントプランニングミーティングの終わりまでに、スクラムチームはスプリントバックログを作成する。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

  16. Scrum Guide (LeSS Version) — 「スプリントバックログは、スプリントゴール（Why）、スプリントに持ち込むために選択されたプロダクトバックログアイテム（What）、およびインクリメントを届けるための具体的な実行計画（How）で構成されている。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  17. Scrum Guide 2010（ライセンス: ライセンス不明） ↩

  18. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「上位オブジェクトであるNexusスプリントバックログ（Nexusスプリントゴールにすべてのスクラムチームのプロダクトバックログアイテムが追加されたもの）は、すべてのスクラムチームによって更新される（Ex10）。」（原文: “The high-level object Nexus sprint backlog (Nexus sprint goal added by the product backlog items from all Scrum Teams) is updated by all Scrum Teams (Ex10).”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  19. Nexus Guide — 「スプリントバックログは、各スクラムチームが保持しており、Nexus スプリントゴール を達成するための作業を明らかにするものである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  20. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩ ↩2

  21. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「各スプリントの開始時にチームはスプリントプランニングに参加し、バックログ内のアーキテクチャタスクに優先順位が付けられた。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  22. Scrum for safety: an agile methodology for safety-critical software systems — 「ここでのスコープはスクラムと同様であり、すなわち、明確で実現可能な目標（スプリントゴール）から始めて、扱いやすく最も重要なストーリー群（スプリントバックログ）を選択することである」（訳）（ライセンス: CC BY 4.0） ↩

  23. A Novel Technique to Assess Agile Systems for Stability — 「スクラムガイドは、プロダクトオーナーが管理し動的に優先順位付けする「プロダクトバックログ」と、「スプリント計画イベントでチームによって選択される」「スプリントバックログ」（プロダクトバックログから利用可能な容量に基づいてアイテムを選択）という二つのキューを定義しています」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  24. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  25. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「プロダクトバックログとスプリントバックログは、さまざまな企業間でテーラリングされた2つの主要な作成物である。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  26. The impact of working from home on the success of Scrum projects: A multi-method study — 「しかし、一部の個人はバックログを扱う物理的な行動を恋しがっています。デジタル形式になったことで、デスクワークの中でのある種の身体的活動が得られなくなっただけでなく、スプリントの状況、各メンバーが何に取り組んでいるか、誰が対応可能かを素早く確認することが妨げられているためです。」（訳）（ライセンス: CC BY 4.0） ↩

  27. Scrum: A Systematic Literature Review — 「スプリントバックログが作成・実行され、そこではタスクがチーム全体に分割され、各サイクルに対するそれぞれのゴールが定義される。」（訳）（ライセンス: CC BY 4.0） ↩