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

受け入れ基準 (Acceptance Criteria)

概要

Section titled “概要”

受入条件（受け入れ基準）とは、プロダクトバックログ項目やユーザーストーリーごとに定義される、具体的かつテスト可能な要求基準および合格判定条件である。プロダクト全体の統一的な品質標準である「完成の定義」を補完し、個々の項目固有の機能・動作や境界条件を明確化して曖昧さを排除する役割を持つ。開発・テストの客観的な検証基準や設計ガイドラインとして機能し、自然言語からBDDによるテスト自動化、ブロックチェーンでの自動判定に至る多様な形式で運用される。また、大規模アジャイル開発では決定権限や運用方針に差異があり、特定の役割が明示的な決定権を持つ枠組みもあれば、チームとの合意形成や自律性を重視して独断的な設定を避ける枠組みも存在する。

詳細

Section titled “詳細”

初期のスクラムガイドや標準的な実践では、項目が「完成」あるいは「完了」したと判定するためにパスすべきテスト手順や検証基準を示すテキスト記述として扱われ、開発チームが機能を正しく実装できたかを客観的に確認するための指標とされている[1][2]。また、個別アイテム固有の要求を記述し曖昧さを排除する側面に加え、該当する基準を満たすことでアイテムのアウトプットが完了したと判定される具体的な完了条件としての側面も定義されている[3]。さらに、ストーリーが意図通りに開発され品質を満たしているかを検証する要件基準としての役割が示されている[4]。アクセシビリティに焦点を当てたユーザーストーリーの文脈では、適合性の判定基準や設計ガイダンスとして機能するだけでなく、音声入力ナビゲーションの動作性や同期キャプションの表示といった具体的要求を検証可能な基準に変換し、開発成果物がエンドユーザーにとって実効性を持つ「完成」状態にあることを保障する役割を担う[5]。

これらはJBehave等のBDDツールを通じて自動実行可能な受入テストコードにマッピングされ、実装のガイドおよび検証手段として機能する[6]。また分散型開発のフレームワークにおいては、テスト層でスマートコントラクトを実行して受入条件を自動検証し、合格・不合格の自動判定や、期限超過に伴うペナルティ情報をブロックチェーン上に透明に記録する手法も存在する[7]。

あるフレームワークでは、プロダクトオーナーがイテレーションの受け入れ基準を決定する明示的な権限を持ち、チームとの連携を通じて設定する運用が規定されている[8]。また、これに関連するビジネスニーズの検証プロセスとして、チームがビジネスオーナーと協調し、計画された目標がビジネス要件を満たしているかを判断・承認する仕組みも取り入れられている[8]。一方で、受け入れ基準に関する詳細な規定をあえて設けないフレームワークや、プロダクトオーナーが単独でチームの成果物の受け入れを決定する運用に対して批判的であり、チームの自律性や合意を重視するフレームワークも存在する[8]。

受け入れ基準は、特定のプロダクトバックログアイテムを受け入れる条件として、プロダクトオーナーやステークホルダーが求める一連の要件である[9]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Acceptance Criteria Quality Requirements
  • カテゴリー: Scrum Core

オントロジー上の位置

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

Process Constraints (プロセス制約)

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

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

  • S2 (AcceptanceCriteria): 受け入れ条件はFunctionalAcceptanceCriteriaかNonFunctionalAcceptanceCriteriaのいずれか一方に分類してください。

脚注

Section titled “脚注”

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

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

  3. Scrum Guide Expansion Pack — 「受け入れ基準は、アウトプット完成の定義でまだ扱われていないプ ロダクトバックログアイテム固有の機能的・非機能的な基準を含む。」（ライセンス: CC BY-SA 4.0） ↩

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

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

  6. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development — 「受入条件は一連のシナリオを通じて定義され、各シナリオにはタイトルと3つの主要な節があります。」（訳）（ライセンス: CC BY 4.0） ↩

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

  8. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「SAFeではPOがイテレーションの受入基準（SP9）を定義するのに対し、他のフレームワークは受入基準に関する情報を提供していないか、推奨されないと明示しています（例：LeSS）。」（原文: “In SAFe, the PO defines acceptance criteria (SP9) for an iteration, whereas other frameworks either provide no information about acceptance criteria or explicitly state that it is not recommended (e.g., LeSS).”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  9. On the Benefits And Problems Related to Using Definition of Done — A Survey Study — 「ACは、特定のプロダクトバックログアイテムがプロダクトオーナー、顧客、ユーザー、またはその他のステークホルダーによって受け入れられるために満たされなければならない一連の要件である」（訳）（ライセンス: CC BY 4.0） ↩