完了定義 (DoD)は、チームが完了として呼び出すことができるように、ユーザーストーリーが準拠する必要がある要件のリストです。
ユーザーストーリーの 受け入れ基準 には、ソフトウェアが期待どおりに機能するかどうかを確認するための要件を満たす一連のテストシナリオが含まれます。
ユーザーストーリーはいつ完成しますか?
つまり、ユーザーストーリーを完成させるには、DODと受け入れ基準を満たす必要があります。両方のリストが完了していない限り、製品の増分は完了したとは見なされません。したがって、DoD定義の2つの側面、つまり完了基準と受け入れ基準を定義する必要があります。
完了の定義
完了の定義はアイテムのリストとして構成され、各アイテムはストーリーまたはPBIを検証するために使用されます。これは、開発チームが作成しようとしている作業の品質について合意することを保証するために存在します。これは、各 製品バックログ アイテム(別名PBI)またはユーザーストーリーの完全性をチェックするために使用されるチェックリストとして機能します 。「完了」の定義の項目は、単一のユーザーストーリーだけでなく、製品バックログのすべての項目に適用されることを目的としています。
それは次のように要約することができます:
- この用語は、製品の増分全体に適用されます
- ほとんどの場合、この用語は、製品の増分が出荷可能であることを意味します
- この用語はスクラムガイドで定義されています
- チームメンバー間のコミュニケーション手段として使用されます
- 全体的なソフトウェア品質
- 増分が出荷可能かどうか
例—完了の定義
- コードピアレビュー?
- コードは完成しましたか?
- コードを確認しましたか?
- コードをチェックインしましたか?
- ユニットテストに合格しましたか?
- 機能テストに合格しましたか?
- 受け入れテストは完了しましたか?
- プロダクトオーナー がレビューして承認しましたか?
合否基準
ユーザーストーリーは アジャイル開発の主要 な 開発成果物の1つですが、 スクラム ではユーザーストーリーまたは受け入れ基準のいずれかを明示的に使用する必要はありません。製品のバックログアイテムが大きすぎてスプリントに入れることができないと考えられる場合、通常はユーザーストーリーに分割され、その後、図に示すように一連のタスクに分割されます。
ユーザーストーリーは受け入れ基準をカプセル化しているため、スクラム開発プロセスで完了基準と受け入れ基準の定義が共存していることがよくあります。ユーザーストーリーは、チームが提供する必要のある機能のコンテキストを提供します。受け入れ基準は、前述の機能の詳細と、顧客がそれらをどのように受け入れるかについてのガイダンスを提供します。それらの2つは一緒に全体の成果物を提供します。
受け入れ基準のいくつかは、スプリントが開始する前の進行中のバックログ詳細化イベントで発見され、他の基準は、 スプリント計画の直後 に座って小さなチームでユーザーストーリーについて話し合うときに発見されます。したがって、受け入れ基準は、ユーザーストーリーまたは製品バックログアイテムに固有の属性です。
- この用語は、個々のPBI /ストーリーに適用されます
- 受け入れ基準は、PBI /ストーリーごとに異なります
- 用語はスクラムガイドで定義されていません
- 特定のPBI /ストーリーの要件が満たされていることを関係者全員に伝える方法として使用されます
- 別名受け入れテスト、満足の条件、場合によっては「テストケース」など
受け入れ基準のあるユーザーストーリーの例
次の図は、ユーザーストーリーの受け入れ基準の例を示しています。