ユーザーストーリーは「＜人＞として、＜何＞をしたい。なぜなら＜理由＞だからだ」といったシンプルで短いフォーマットで表現されます。ただ、実際の現場ではユーザーストーリに詳細な仕様や受け入れ条件が書かれていることも多いでしょう。先述のフォーマットだけだと作れないですからね。ただ、ユーザーストーリーは短いことに意味がある点に注意するべきでしょう。
シンプルで短いフォーマット
ユーザーストーリーは、顧客の目に見える機能単位です（XPエクストリーム・プログラミング入門―変化を受け入れるより）。「ユーザに提供する価値が書かれた短い文章」と表現される場合もあります。
ユーザーストーリーはなぜ、シンプルで短いフォーマットになっているのでしょうか？
理由のひとつは、要件と呼ばれる実装必須のフォーマットを利用した場合、そのほとんどが利用されないからです。XP本では「システムの20％か10％、あるいは5％配置しただけで、システム全体に想定されるビジネス上の利益をすべて認識することになるだろう」とあります。製品機能の64％は使われていないという有名な調査もあります（この調査は市販される製品の話ではなかったのでデータとして良くない気もするが）。よって、「使われない機能まで書いてしまわないか？」という問いにユーザーストーリーで答えたのかもしれませんね。
ふたつめは、見積もりのはやさです。情報量が多いと精密な見積もりができますが時間がかかります。一方で、見積もり手法にもよりますが、ユーザーストーリーを使った見積もりはすばやいですが、見積もりの精度は低くなるでしょう。見積もりがはやくできるということは、はやくリリースできることにつながります。
3C
ユーザーストーリーはプロダクトの要件のなかで「誰が」、「何を」、「なぜ」求めているかを簡単に把握する方法です。
ユーザーストーリーは上記のようなインデックスカード（Card: 情報カード）に記述します。インデックスカードは付箋2枚分よりちょっと大きいサイズのカードです。ユーザーストーリーがシンプルで短いフォーマットであるのと同時に、インデックスカードによって書く量が制限されます。
制限された情報量しかないので、実装のためにはもっと情報が必要です。そのためには、対話（Conversation）が必要になります。
対話によって得た開発に必要な情報はどこかに残したくなります。現在では、RedmineやJIRA、最近だとNotionといったチケット管理システムの利用が主流なので、そこに追記するケースも多いでしょう。
集まった情報の中には、確認のための受け入れ条件（Confirmation）が書かれています。
Card（カード）、Conversation（対話）、Confirmation（確認）の3つの頭文字をとって、これを3Cと言ったりします。ユーザーストーリーの書き方についてはINVESTも有名なので、興味があれば調べてみるとよいでしょう。
ユーザーストーリーにめっちゃ仕様を書いている問題
ここまでで古典的なユーザーストーリーの解説をしました。古典的と表現したのは、今の開発現場で、情報カードを貼り付けて開発しているところは少ないと思ったからです。
古典は古典でしかないですが、古典から学べることもあります。
もし、現在、ユーザーストーリーにめっちゃ仕様や受け入れ条件を書いているとすれば、ユーザーストーリーが狙っていた効能を得られていないかもしれません。ユーザーストーリーの効能は以下です。
- 必要なものだけを作る
- すばやく見積もりできる
- 対話と確認で理解を深める
特に3つ目の対話は、アジャイル開発が重要視するコミュニケーションに関係する重要な要素です。
上記は、自分が支援する現場でよく見かけるフォーマットをまとめたものです。たいていはチケット管理システム（タスク管理システム・ツール）に自動でフォーマットが挿入され、それを埋めていく方法が取られています。とても便利な方法です。
これらは開発に必要な必要最低限の情報とも言えます。ただ、ユーザーストーリーはそのフォーマットや内容よりも、結果に至るまでのコミュニケーションも重要視したツールです。
たとえば、POが一生懸命ストーリーに仕様や受け入れ条件まで記述しているとすれば、（それはそれで開発しやすいかもしれませんが）対話の効果が得られません。POが優秀だったり、エンジニア出身で実装まで検討できるとなると、「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれないみたいなことがおきちゃうかもしれない。
果たしてそれでいいのか？ チームで考えてみると良いでしょう。
旅と子育てとアジャイルコーチのブログ「世界」 