プラクティス名（別名）
受け入れ条件 （受入基準、AC、Acceptance Criteria）
プラクティスの目的・狙い
- プロダクトバックログアイテム（PBI）の完了基準を明確化する
どんな時に使うか
- POとDEVの間でPBIが何をもって「完了」となるのか認識齟齬が頻発する時
実施手順
- そのPBIは何をもって「完了」となるのかPOとDEVで具体的な基準について話し合う
- ACは直接POがPBIに追記する（または話した内容をDEVが書き下しPOと合意する）
- PBIを完了させる時には「受け入れ条件」「完成の定義」両方を満たしていることを確認する
ACの適切な記述粒度はケースバイケースだが、「POとDEVが齟齬無く完了/未完了を判断できる」という点が目安となる。ただしACに例外処理などアプリの詳細仕様を漏れなく書こうとするとPBLが重くなりすぎるので避けた方がよい。ある程度、会話で補完することも必要。
アレンジ例
- ACをユーザの操作手順として記述し、スプリントレビューではその手順に沿ってデモを行う
アンチパターン
- ACを書くのはPOの仕事と、任せきりにした結果、POが回らなくなる
- DEVがPOに「ACにそんなことは一言も書いてありません」と言う。
（これを口にしてしまうと、以後、ACが契約と化していく） - 「受け入れ条件」と「完成の定義」の記述が混在してしまっている
受け入れ条件：そのPBI固有の完了条件
完成の定義 ：全てのPBIに共通する完了条件
参考情報
こぼれ話（私的コメント）
真面目なPOほどACをきちんと書こうとしてボトルネックになりがちな気がします。DEVが「ACに書かれていないことは一切やらなくてよい」と考えるタイプだと特に。個人的な意見としては、たとえPOからの指定がなかったとしても、システムのプロとして、あるべき姿を考え、仕様を詰めていくのは「設計」の領域であり、DEVの責任だと考えます。つまるところACはコミュニケーションツールだ、という前提に立てば、記述云々よりも共通認識が作れているかどうかが大事、という理解にたどりつけるのかな、と思います。