プロダクトバックログに受入条件・受入基準が必要な理由

プロダクトバックログアイテムには最低ひとつの受入条件が必要だ。受入条件がない要求は、できたのかできていないのか判断がつかない。

全てのプロジェクトには目的があり、ゴールがあり、そして受入条件がある。

魚釣りを例に考えて見よう。

魚を釣る行為はおなじでも、その目的は様々である。

ゲームフィッシング
自分や家族が食べるため（自給自足）
売るため（事業用）

もちろん混合型もあるだろう。ゲームフィッシングの後、釣れた魚をいただくこともあるだろうし、事業用であっても、残ったら従業員でいただくケースもある。ただしその場合でも受入れ条件は変わる。

ゲームフィッシングの代表はマグロやカジキだ。ゲームなので、ゴールは魚のサイズ、あるいは何尾釣れたか。受入条件は魚を釣り上げて、ボートの中に収容すること。魚をボートに収めたタイミングでゴール達成となる。ゲームフィッシングなら釣る過程そのものも楽しみだろう。ゴールは達成できなくても（釣れなくても）、ゲームフィッシングに参加したことで目的のいくらかは達成できるかもしれない。

一方、食用や事業用なら、過程は楽しい必要はない。目的は大きな魚や多くの魚を釣り上げることである。釣れなければゴールはもちろん、目的も達成できない。そして釣り方も時間をかけず、魚の身が焼けないようにして、釣り上げたら即内臓を取り出して冷やす加工も必要になる。おいしくなくては高く売れない。事業用でも、銀座の一流店に直送するなら受入基準も厳しくなる。朝取れなら何時までに港に戻り、午前〇X時の飛行機に乗せるとか、複数の受入条件、厳しい基準を満たさなくてはならない。

目的によってゴールは変わる。そしてゴールには判断するための受入条件が伴う。対象となる利用者によっては、受入条件の基準も変わる。

スクラムのプロダクトバックログも同じである。プロダクトの目的は何か。目的が明確なら、個々のプロダクトバックログアイテムのゴールも明確になる。そして、ゴールしたと判断できる受入条件（ある・なし）と受入基準（どれだけ）を確認する。受入条件/基準まで開発チームが理解して、やっと正しい作り方を考えられる。目的とゴールが混同されていたり、ゴールが曖昧なまま開発しないよう注意しよう。