「受入基準」と「完成(Done)の定義」は別物である。
でも、被せることで頻繁にリリースできるようになります。
受入基準は、プロダクト・オーナーや顧客が満足するレベルのことです。
例えば、利用者が自分の基本情報を登録できる「マイ・メニュー画面」が欲しいとします。
登録内容は、
- 氏名
- 住所
- 電話番号
- メールアドレス
- 連絡事項
だとしましょう。
そして、氏名、住所、電話番号、メールアドレスは「必須項目」だとします。
必須項目が未記入の場合、登録は完了できません。必須項目がすべて入力されて、はじめて登録完了することがPOの「受入基準」になります。
ここでいう受入基準は、「マイ・メニュー画面」全体の受入になります。必須な項目セットを満たしていないと、そもそも登録ができませんからリリースできません。
一度に全項目を制作できない場合は、各項目単位で受入基準を満たすようつくります。たとえば、「氏名」フィールドについて。漢字とカタカナ表示できて、桁数は全角20桁まで対応できて、未記入だと注意喚起される等。エンジニアは個々の項目について実装し、全ての項目セットが整ったところでPOにリリース判断してもらいます（マイ・メニュー画面機能としてのフィーチャーセットの受入チェック）。
一方、「完成(Done)の定義」は、開発チームが、プロダクトインクリメントを「完成」と判断するレベルを指します。
エンジニア全員で共有します。
開発チームは2週間のスプリントではパーツ機能を作るだけで精一杯かもしれません。その場合、各自の端末でコーディングして単体テストを実施するまでを「完成(Done)の定義」とします。
田中さんは名前の外字対応、山本さんは郵便番号による住所検索、木村さんは固定・携帯電話の桁数ロジック、伊藤さんは各フィールドに値が入力されていることをチェックするアラート・ロジックを構築します。
このケースでは、各自のプログラムが単体テストまでは確認できても、結合して全てが連携して動作することは確認できていません。コードベースにパーツ機能をがっちゃんこして、統合された状態で動作しているかのチェック（統合テスト）、顧客画面の印象やレスポンスの早さ等、操作性のチェック（ユーザー受入テスト）は、次のイテレーションで検証することになります。
「完成(Done)の定義」はチームの成長に従い拡張していきます。
やがて、PO・顧客が求める受入基準まで一回のイテレーションで作り込めれば、「完成(Done)の定義」と利用者の「受入基準」を同時に満たすことになりますから、イテレーション毎にリリースできることになります。
開発当初は、開発チームの「完成(Done)の定義」はPOの「受入基準」に満たないかもしれません。
最終的にゴールを同じレベルに設定することで、「完成(Done)の定義」を満たしたら、即、リリース可能なインクリメントが仕上がることを目指します。
本来、「完成の定義」はひとつですが、段階的に完成度を高めていくことを、以下に説明しています。併せてご確認ください。