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

バックログアイテム (Backlog Item)

概要

Section titled “概要”

プロダクトバックログアイテムは、プロダクトの価値向上や課題解決のために実施すべき要求や要件を表す作業および価値の最小単位である。粗粒度の要求から低粒度のユーザーストーリーまで多岐にわたり、リファインメントを通じてスプリント内で完成可能なサイズに細分化される。サイジングや見積もりは開発者の自律性に委ねられるが、大規模環境ではアイテムの分解やチームへの割り当てが自律性の制御点となり、依存関係や見積もりの不整合といった課題が生じる。また、フローの最適化やキューイングシステムにおいては、到着率やサービス率を測る基本単位として機能し、未完了離脱と完了の適切な判別が求められる。アイテムの適切な管理と自律的な意思決定プロセスの確立は、進捗の破綻を防ぎ、プロダクト価値の最大化と実証的適応を果たすための中核を担う。

詳細

Section titled “詳細”
  • 定義と目的、価値への接続：プロダクトバックログアイテムは、プロダクトに追加・改善されるべき機能、要求、要望、修正内容、またはチームのシステム（ワークフロー）を通過する価値の単一の単位であり、プロダクトの有用性や価値を高めるための具体的な要求事項を表す[1][2][3][4][5]。プロダクトバックログやリリースバックログ等に記録される要件やタスクの個々の項目を指し、粗粒度の高レベル要件から低粒度のユーザーストーリーまでその粒度は多岐にわたる[6]。単なる機能追加やアウトプットの列挙に留まらず、ステークホルダーの問題や機会に対処し、潜在的な価値や成果（アウトカム）を発見・提供することを目的とする[7][8]。保持する属性の定義は変遷しており、詳細（明確さ）、優先度、見積もりを中心とする定義[1][9]や、明確さ・優先度・見積もり・受入条件を挙げる場合[1]、詳細説明・並び順・見積もり・価値とする場合[2][10][7]、説明・見積もり・価値とする場合[5]、説明・並び順・サイズとして表現される場合がある[3]。また、一般的なビジネス価値に加え、学びを得る「知識の価値」や「プロセス改善の価値」といった多角的な観点も含まれる[4]。
  • 記述形式と検証基準・進化性：アイテムの記述形式は特定のフォーマットに固定される必要はなく、チームにとって意味のある形式が選択される[8]。一般的にはユーザーストーリーやユースケースなどの形式が用いられる[1]。検証基準として「完成」の定義を満たしているか確認する受け入れ基準（受入テスト/条件）[1][11][10][12][8]に加え、なぜその作業するかを示す成果基準（アウトカム条件）が含まれることもある[8]。アイテムはリファインメントの過程のみならず、実際の開発作業中であっても常に進化・更新・適応される可能性がある[8]。アイテムの明確化はプロダクトオーナーと開発チームの協働によって進められ[13]、クライアントやエンドユーザー、サポートチームなど多様なソースから直接アイテムが追加される運用も存在する[14]。
  • トレーサビリティとフロー・経過時間の管理、システム工学的分析：成果物のデザイン決定を実証的根拠と結び付けるアプローチにおいては、デザインジャーナル等と連携させることでアイテムの追跡可能性（トレーサビリティ）が確保・管理される[15]。また、ワークフロー上を可視化・追跡する手法においては、作業が開始されてから終了するまでの経過時間（サイクルタイムや作業項目の年齢）を追跡・計測し、価値提供のフローの最適化に活用される[4]。さらに、システムの安定性評価等のキューイングシステムにおいては、バックログアイテムは実証データの分析対象およびキューの到着単位として位置づけられ、到着率（λ）や成功裏に処理された完了単位としてのサービス率（μ）の算出根拠となる[16]。Jira等の課題管理システムにおいては、解決（Resolution）が付与されることで処理完了と判定されるが、未完了のまま離脱・破棄されるアイテムとの適切な判別が必要とされる[16]。
  • リファインメントと分解・適応・選定プロセス：アイテムはリファインメント（手入れ）を通じて詳細の追加や細分化が行われ[9][2][3][7]、観察やエビデンスを通じた特定、検査、リファイン、適応のプロセスを経る[8]。特に優先順位の高いアイテムほど明確かつスプリント内で対応可能なサイズへと分解・細分化され[1][11][9][2][10][5]、1スプリントのタイムボックス内で「完成」定義を満たせる「準備完了（Ready）」の状態でスプリント計画に持ち込まれる[1][9][2]。スクラムの原則に適合させる観点からも、通常2週間から最大1ヶ月以内のスプリント期間で完了できる粒度への分割が求められる[16]。イテレーション計画において、開発者はアイテムを分解しサイズを決定する自律性を持つ[17]。スプリントバックログへ取り込まれ「完成」することでインクリメントの一部となる[1][3][12][13]。大規模・多チーム環境では、クロスチームリファインメントを通じて単一チームがデリバリーできるレベルまで分解される[18]。
  • 見積もり責任、リスク・依存関係とテイラリング：見積もりについては、チーム全体によって実施されるとされる場合もあるが[1]、作業を担う開発チーム（プロダクト開発者）のみがサイズ見積もりを決定する最終的な責任を持つとされる[2][10][8][5]。見積もりでは作業量や複雑さに加え、リスクや依存関係の特定が考慮される[11][18][13]。一方で現場の実践におけるテイラリングの事例として、見積もりせずにスプリントプランニングへ投入したり、厳密な優先順位付けを行わずに管理する手法が選択されることもある[14]。ただし、見積もりのないバックログアイテムの運用は、非現実的なスプリントゴールの設定や進捗管理の破綻につながる懸念も指摘されている[14]。
  • 大規模開発における自律性と管理課題：大規模アジャイル開発では、特定チームへのアイテム割り当てや依存関係の解消、上位レベルのバックログから個別チームのストーリーへの分解プロセスがチームの自律性の制御点となる[17]。チーム・オブ・チームズの計画イベントで特定のバックログアイテムがチームに割り当てられることで自律性が制約される場合がある一方[17]、LeSSの初期計画段階では開発チーム全体（または代表者）がどのチームがどのアイテムを最初にデリバリーするかを自律的に決定するアプローチや[17]、SAFeのPI Planningにおいてバックログアイテムをチームが自律的にストーリーへと分解してPI Objectivesを策定するアプローチなどが存在する[17]。同時に、大規模スクラムにおけるアイテム管理特有の課題として、チームの関与なしに高レベルで粗粒度なアイテムの見積もりが行われることで作業の手渡し時期が不正確になる「見積もりの不整合」、明確な基準の欠如やチーム間の同期不足によって機能の同時納品が困難になる「優先順位の不一致」、ならびに依存関係にあるチーム同士で共通理解が不足することで予期せぬブロッカーが発生する問題などが報告されている[6]。さらに、アジャイルリリーストレイン（ART）の同期イベントにおいて、共有サービスなどの専門機能がバックログアイテムに関連する技術的・専門的な問題の解決を支援する対象としても言及されている[19]。
  • 未完成アイテムの扱い：スプリントの中止や再計画等により「完成」に至らなかったアイテムは、再見積りが行われた上でプロダクトバックログに戻される[2]。

バックログアイテムは、プロダクトオーナーによって定義され、スプリントプランニングでの評価を経てスプリントの実装タスクとして選択される構成要素である[20]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Scrum Artifacts Work Item
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”
  • 上位クラス（直接の親から順に）: Artifact → Measurable_Software-Related_Entity → Measurable_Entity
  • 兄弟クラス: Composite_Artifact、Increment、RequirementsArtifact、Software_Item
  • 他の概念との関係: 未定義
  • 関連する検証ルール: 未定義
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

脚注

Section titled “脚注”

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

  2. Scrum Guide 2013 — 「リファインメントされ たプロダクトバックログアイテムは透明化され、スプリントプランニングのインプットとして 十分に理解可能であり、適切な粒度となっている。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Scrum Guide 2020 — 「スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれら を提供するための計画をまとめてスプリントバックログと呼ぶ。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

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

  5. Scrum Guide (LeSS Version) — 「プロダクトバックログは、プロダクトを進化させるために必要なプロダクトバックログアイテムが並べられた、インクリメンタル（漸進的）なリストである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  6. Systematic Literature Review Report on the Challenges of Agile Scrum — 「本稿の文脈において、チーム間コミュニケーションとは、相互依存関係にあるアジャイルスクラムチームが、ソフトウェア成果物（バックログアイテム、リリースイテレーション計画、アーキテクチャ、他チームの進捗状況、フィーチャやソフトウェアコンポーネント間の依存関係などの共通理解を含むがこれらに限定されない）に関する「共通知識」をどのように獲得できるかとして定義する。」（原文: “In our context, we define Inter-team communication as how a codependent agile scrum teams can come to have “common knowledge” on software artefacts, which includes but not limited to common understanding of backlog items, release iteration planning, architecture, progress of other teams, and dependencies among features as well as software components.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2

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

  8. Scrum Guide Expansion Pack — 「プロダクトバックログアイテムは、プロダクトバックログ内にある潜在的に価値のあるア イテムである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

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

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

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

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

  13. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  14. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「さらに、プロダクトバックログアイテムは、クライアント、エンドユーザー、サポートチームなどのさまざまな情報源から届く[3]。」（原文: “Additionally, product backlog items arrive from various sources such as clients, end-users and the support team [3].”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  15. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩

  16. A Novel Technique to Assess Agile Systems for Stability — 「当社はこの指標を用いて、Jiraプロジェクト926個および14社の160万件以上のプロダクトバックログアイテムを分析しました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  17. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「一方で、他のフレームワークと同様の考え方に従い、プロダクトバックログアイテムの優先順位付けについてはプロダクトオーナーのみが責任を負う。」（原文: “On the other hand, following the same idea as in different frameworks, the Product Owner is the only one responsible for prioritizing the product backlog items.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  18. Nexus Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2

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

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