アジャイルでは一般的に要求を「ユーザーストーリー」形式で表現する。ユーザーストーリーは顧客視点で書かれる。だから顧客にとっての価値を表わしている。
ユーザーストーリー単位で作れば、そのユーザーストーリーが持つ顧客価値が実現できる。
ユーザーストーリーは以下のフォーマットだ。
- ユーザー”～”として
- “～”が欲しい
- なぜなら”～”だからだ
そして、ユーザーストーリーと一緒に「受入基準」も設定する。受入基準とは、プロダクトオーナー（顧客）がユーザーストーリーを「完成品」として受け入れる基準である。
開発チームが品質基準として自分たちの「完成」を表明する「完成の定義」とは別ものであるので注意して欲しい。「完成の定義」は、コードの品質を担保したり、結合テストをして総合的な動作確認をしたりする作り手が掲げる品質基準である。使い手である顧客が定義する受入基準に加えて、多くの項目が含まれ、より包括的である）
ユーザーストーリーの「受入基準」を定義するポイントは5つだ。
- yes/noで判断できる。定量的であったり客観的に判断できるもの
- ソリューションに依存しない
- 機能要件に加え、非機能要件も含む
- 受入基準単位で受入テストが可能
- 実装前に定義される
yes/noで判断できる。定量的であったり客観的に判断できるもの
「顧客ニーズを満たす」だけでは不十分だ。どんな状態になったら受け入れてもらえるのか、客観的に定義しよう。POによる受入判断前に、開発チーム自身で受入可否が判断できる客観性がなくてはならない。
ソリューションに依存しない
ユーザーストーリーは顧客視点で、顧客の言葉で表現される。だから、その受入基準も技術的なソリューションや仕様は含まない。お箸でも、フォークでも、手掴みでも、食べ方に関わらずおいしく顧客が満足できるものでなくてはならない。
採用されるテクノロジーやシステム仕様に左右されず、利用者視点で要求が満たすべき基準を定義しよう。
機能要件に加え、非機能要件も含む
受入基準は機能要件のみならず、非機能要件も定義する。機能要件はプロダクトが「なに」ができるか。非機能要件はプロダクトが「どれだけできるか(How much)」の定義である。
受入基準単位で受入テストが可能
ユーザーストーリーには最低1つの受入基準が必要だ。複数ある場合、その受入基準毎にテストできる。だから、受入テスト単位でストーリーを分解することもできる。例えば、おいしいアップルパイを作る際、「おいしそう」「いいにおい」「うまい」の3つの受入判断があるとする。個々の受入基準を客観的に定義する必要があるが、それぞれの受入基準毎に作って、テストしてもいい。
まず「おいしそう」なパイをつくる。実はにおいが酷かったり、まずくても構わない。
「おいしそう」な見栄えのするパイを実装する。次に「いいにおいだ」。最終的に「おいしそう」「いいにおい」「うまい」ができた時に顧客に届けられる（リリースできる）。
実装前に定義される
受入基準は、スプリントでユーザーストーリーに取りかかる前に明確にする。だから、プロダクトバックログのリファインメント（手直し）や、スプリントプランニング時に定義する。
従来型でよく見られるように開発フェーズで定義してはいけない。実装前に前もって定義し、POと顧客が受け入れる水準を掴んだ上で、かかる作業を見積り、実装にとりかかる。
以上が、ユーザーストーリーで定義する「受入基準」の5ポイントである。
要求をなんとなくストーリー化している場合は、受入基準も併せて定義しよう。受入基準を定義すれば、受入テストであるスプリントレビュー時のデモパターンや手順も明確化される。是非お試しあれ！
プロダクトマネジメントの要諦 The Rules of the Game of Product Management 