プロダクトバックログアイテム(PBI)が完成したか、リリース可能と言えるかどうかは、開発チームとプロダクトオーナが判断する。判断基準は様々で、ちゃんと動くか、使いやすいか、重かったりしないか、デザインが整っているか、脆弱性が存在しないか、SLAを満たすか、十分テストしてあるか、アーキテクチャの一貫性を壊していないか、ドキュメントは書いてあるか…… どういう基準が必要か、基準をどのくらい緩く、厳しくするかは、プロダクトとチームによって千差万別になる。
受入条件は判定基準として、個々のプロダクトバックログアイテム固有になる。このように機能すること、動作がこうであること、前提がこうなら結果がこうなる、などのPBI個別で定める内容になる。言い換えると、受入条件はPBIの内容の一部、PBIがどんなものか説明する一部だ。PBIをユーザーストーリーで書いていれば、ユーザーストーリーは「プロダクトオーナーと開発チームが会話する約束」なので、会話の中に受入条件が登場し、相互に理解して、スプリント終了までに判定すると約束する。
完成の定義(Definition of Done)は、すべてのプロダクトバックログアイテム共通となる判定基準だ。 プロダクト全体で守るべき非機能要求や、組織・開発・運用などの観点から制約される、あるいは達成したいラインによって構成される。完成の定義は開発チームとプロダクトオーナーが相談して定める。
受入条件も完成の定義も、誰かが判定しなくてはならない。開発チームとプロダクトオーナーが議論したり伝達したりするものだが、最終的に判定する責任は誰にあるのか。受入条件はPBIの内容の一部であり、従ってプロダクトオーナーが責任を持つものだ。そのため判定するのはプロダクトオーナーである。プロダクトオーナーが受入条件を元に自分で受け入れテストを作り、自分でテストするというのが純粋な形となる。この部分だけ取り出すと、請負契約の納品物を発注者の責任で検収するのと同じ構図になる。
完成の定義は開発チームが判定するものである。PBIが完成したと言えるかの条件であり、すなわちリリース可能であるか、スプリントレビューの対象とできるか、受け入れ判定をしてよいかの条件である。受け入れ判定をする前に完成の定義の判定をクリアしないとならない。いっぽう、完成の定義は、PBIが完成してるのかどうか、透明性を高めるための道具立てでもある。そう考えると完成の定義は、判定のための仕事をしなくても判定できるような、見える化や自動化を進めるべき領域でもある。
