ほとんどの新機能はユーザーの視点から定義されるべきですが、実際には開発チームが構築する必要がある要件を定義する際、ユーザーの視点からの「なぜ」をしばしば無視してしまいます。ユーザーストーリーの焦点は経験にあり、製品を使用する人が何を達成したいかということです。従来の要件は機能性に焦点を当てており、製品が何をすべきかということです。残りの違いは、繊細ではあるが重要な「誰が」「どのように」「いつ」のリストにあります。

ユーザーストーリーは1〜2文で記述し、ユーザーが誰であるか、何を望んでいるか、そしてその理由を捉えます。機能やユーザーストーリーを定義するためのシンプルな構造は以下の通りです:
~として、私は~したい。なぜなら、~できるようにしたいからである。
例:
ユーザーとして、パスワードをリセットしたい。なぜなら、忘れてしまった場合にシステムへのアクセスを再開できるようにしたいからである。
異なる目的を持っていますが、ユーザーストーリーと要件の両方とも、顧客が愛する製品を構築することを最終目標としています。
ユーザーストーリーとは何か?
ユーザーストーリーは、最終ユーザーの視点から表現された要件です。ユーザーストーリーはエピック、テーマ、または機能とも呼ばれることがありますが、いずれも同じフォーマットに従います。
本質的に、ユーザーストーリーは明確に表現された要件です。多くの理由から、ユーザーストーリー形式はアジャイルにおける要件の表現方法として最も人気があります:
- 解決策を使用するか、影響を受ける人の視点に焦点を当てます。
- その役割にとって意味のある言語で要件を定義します。
- 要件の背後にある真の目的を明確にします。
- 低レベルの詳細に過度に深入りせずに、高レベルの要件を定義するのに役立ちます。
ユーザーの目標を特定し、ユーザーストーリー内の各要件のビジネス価値をすぐに検討します。
ユーザーストーリーは通常、3つの要素を含むとされています——3C:

- CARD – インデックスカードまたはステッカーに記述すべきです。
- C対話 – プロダクトオーナー(プロダクトオーナー).
- C確認 – 正しく実装されていることを確認する。ユーザー受け入れ基準を満たす必要がある。
ユーザーストーリーのフォーマット
ユーザーストーリーのフォーマットは以下の通りです:
~として <役割>, 私は~したい <目標>, そうすることで <利益>
これらの2つの例は、異なるレベルのユーザーストーリーを示していますが、同じフォーマットを使用しています:
プロジェクトレベルでは:
~として <マーケティングディレクター>, 私は~したい <顧客サービスを改善する>, そうすることで <顧客を維持できる>。