コンテンツにスキップ

エピック(分解前の大きなユーザーストーリー)を、そのままスプリントバックログに入れてよいか?

公式仕様・オントロジー検証クエリ(cq-08)。スクラムガイドやカンバンガイド等の公式テキストと、オントロジー(SRO/KGO)の形式検証に基づく解説です。文献の事例報告ではなく、公式ルール上の規定と論理構造を示します。

エピックはそのままスプリントバックログに入れるべきではありません。1スプリントで完成できるサイズのアトミックなユーザーストーリーに分解・リファインメントしてから選択するのがスクラムの前提です。


プロダクトバックログのリファインメントによって、アイテムは1つのスプリントで「完成」できると判断できるだけの十分な情報を持つ「レディー」な状態に詳細化されます。巨大なアイテムのまま計画に持ち込むことは想定されていません。

オントロジー(SRO)による論理構造

Section titled “オントロジー(SRO)による論理構造”

sro:Epicはsro:UserStoryのサブクラスであり、他のユーザーストーリー(sro:AtomicUserStoryを含む)で構成される複合的な存在です。エピックが分解されないままsro:SprintBacklogに直接含まれている状態はモデル上警告されます。スプリントで実行可能なのは、これ以上分解されないsro:AtomicUserStoryの粒度まで落とし込まれた項目です。


根拠・出典一覧(トレーサビリティ)

Section titled “根拠・出典一覧(トレーサビリティ)”
出典種別参照先該当箇所 / 概念
GUIDE『スクラムガイド 2020』プロダクトバックログのリファインメントプロダクトバックログ / リファインメント (Refinement)
SROSROモデル: sro:Epic(リファインメント不足)- sro:isPartOf(sro:SprintBacklog)sro:Epic

🔍 妥当性検証レポート(クリックして展開)
  • 総合判定: ✅ 合格 (スコア: 100/100)
  • 形式論理検証: PASS
  • LLM批判的評価: Faithfulness 5.0/5, Relevance 5.0/5

評価コメント:

  • The answer accurately reflects the provided context, correctly stating that epics should be broken down into smaller user stories before being included in the sprint backlog. It references the Scrum Guide and SRO model appropriately, ensuring it stays within the given information and directly addresses the question. The reasoning is clear and logically consistent with the principles of Scrum.