標準的なユーザストーリーのフォーマットは「roleとして、goal/desireが欲しい。それはbenefitのためだ」というものだ。しかし、誰をroleフィールドに入れるべきかを考えると、こうした正攻法のテンプレートだとしっくりいかないユーザストーリーもある。
例えば、Scrum Developmentメーリングリストの最近のスレッドにおいて、Kevin Krac氏は次のような現実のユーザストーリーについて質問した。
プロダクトオーナーは、購入後に顧客が問い合わせする電話番号を変更する、というストーリーを思いつきました。現在のところ、顧客に送られたメールには、マーケティング部門の電話番号が載っています。でもプロダクトオーナーは、代わりに販売代理店の電話番号を載せた方が賢明だと思ったのです。
このユーザストーリーをフォーマットにあてはめると、roleフィールドには誰を入れるべきだろうか？ プロダクトオーナーだろうか？ マーケティング部門のメンバだろうか？ 販売代理店だろうか？ あるいは、それ以外の誰かだろうか？
そもそも、一体なぜ、ユーザストーリーにはroleフィールドがあるのだろうか？ Don MacIntyre氏はその理由をひとつ挙げた: 「受益者としての役割を明確に特定することは、プロダクトオーナーが明確な価値ある提案を考え出すのに役立つと思います。これはストーリーを優先順位付けするのにも役立ちます」 しかし、このストーリーの場合、開発チームがこれを完了したとき、誰が得をするのかまだはっきりしない。
Ron Jeffries氏は標準的なストーリーの形式にこだわる意味はあまりないと言う。
カードに何を書くかはあまり関係ありません。私は「マーケティング部門の電話番号になっているところをクライアントの販売代理店の番号に変更する。」といった感じでいいと思います。[...]
考えることが重要なのです。最も価値のあるストーリーを選ぶことが重要なのです。チームに対して最終的に決められたことを説明することが重要なのです。そして、それがうまくいっているかを具体的なテストで確かめることが重要なのです。
カードに書かれていることはそれほど重要ではないのです。
しかし、Mike Cohn氏は、標準的なユーザストーリーのフォーマットには利点もあると言う。彼は利点として以下を挙げた。
- ユーザストーリーを一人称で書くこと（「... として ... が欲しい」）は、開発者やその他の人がやっている仕事の受益者になりきるのに役立ちます。
- すべてのストーリーを同じ形式にしておけば、それぞれの文章をひとつずつ頭の中で解釈していく必要性がなくなるので、プロダクトオーナーが優先順位付けするときに役立ちます。
Mike Cohn氏は、標準的ではないストーリーでも標準的なフォーマットにうまくあてはめるためのいくつかのコツを挙げている。
よいユーザストーリーにはシステムのステークホルダーが必要です。そして、ストーリーは 「顧客として、支払いを済ませようとするときに、補完的なプロダクトを見せられる」あるいは「ユーザとして、90日ごとにパスワードを変更するよう強制される」のように「want（欲しい）」以外の同じくらい簡単なものにしても構いません。すべてのストーリーに「want（欲しい）」が必要というわけではありません。
テンプレートがあるということはすばらしいことかもしれないが、ユーザストーリーのテンプレートを埋めることは、やらなくてはならない難しい仕事というわけではないだろう。ユーザストーリーがうまくいくための重要なポイントは、Ron Jeffries氏が言うように、「カード、会話、確認」だ。つまり、要件（ユーザストーリー）を特定するのに十分なテキストでカードを作り、その要件をうまくコードに落とし込めるよう、顧客とプログラマで十分なコミュニケーションをとり、作業の完了結果を受け入れテストによって確認することだ。