アジャイルガイド · アジャイルのプラクティス
ユーザーストーリー：書き方、テンプレート、例
ユーザーストーリーとは、ユーザーが必要とするものを、ユーザーの視点から平易な言葉で短く記述したものです。誰が、何を、なぜ求めているかを捉え、完全な仕様書ではなく、詳細について話し合うためのプレースホルダーとして機能します。
要点
- ユーザーストーリーは、誰が、何を、なぜ必要としているかを示します。
- 受け入れ基準は各ストーリーをテスト可能にし、完成の定義はすべてのストーリーに適用されます。
- INVESTで品質を確認し、1スプリントに収まらないストーリーは分割します。
- ストーリーは会話の出発点であり、完全な仕様書ではありません。
ユーザーストーリーのテンプレート
最も一般的な形式は次のとおりです： 私は ［ユーザーの種類］として、 次のことをしたい： ［何らかのゴール］ 。なぜなら、 ［何らかの便益］からだ。
- 誰が： 「システム」ではなく、特定のユーザーや役割。
- 内容： 技術的な解決策ではなく、ユーザーが必要とするゴールや機能。
- 目的： 便益。これにより、チームは最もシンプルな提供方法を見つけやすくなります。
多くのチームはストーリーを3つのCで説明します。 カード （短く書かれたストーリー）、 会話（Conversation） （詳細を補う議論）、そして 確認（Confirmation） （完了を示す受け入れ基準）。
受け入れ基準
受け入れ基準とは、ストーリーが受け入れられるために満たすべき条件です。ストーリーをテスト可能にし、誤解を減らします。一般的な書き方は2つあります：
- チェックリスト： 「予約にクラスの時間と場所が表示される」「会員が確認メールを受け取る」。
- Given-When-Then： 「クラスに空きがある状態で、会員が［予約］をタップすると、枠が確保され、空き数が1つ減る。」
INVESTチェックリスト
| 文字 | 意味 | 確認すべき問い |
|---|---|---|
| I | 独立している（Independent） | 他のストーリーを待たずに提供できるか？ |
| N | 交渉可能（Negotiable） | 詳細が固定されておらず、話し合いの余地があるか？ |
| V | 価値がある（Valuable） | ユーザーやビジネスに価値をもたらすか？ |
| E | 見積り可能（Estimable） | チームが見積もれる程度に十分理解しているか？ |
| S | 小さい（Small） | 1スプリント内で完了できるか？ |
| T | テスト可能（Testable） | 明確な受け入れ基準があるか？ |
ユーザーストーリーの書き方：ステップごとの手順
- ユーザーとそのゴールを、できればリサーチや実際のフィードバックから特定する。
- テンプレートを使ってストーリーを1～2文で書く。
- 受け入れ基準を3～6個追加する。
- チームと話し合うタイミング： バックログリファインメント 、調整します。
- INVESTに照らして確認し、大きすぎる場合は分割する。
- 見積もる。たとえば ストーリーポイント.
- 並べ替える場所： プロダクトバックログ 価値、リスク、依存関係に基づいて。
例：弱いストーリーと改善版
| 弱いストーリー | 改善したストーリー |
|---|---|
| ユーザーとして、予約用のデータベーステーブルが欲しい。 | 会員として、クラスを予約したい。なぜなら、自分の枠を確保できるからだ。 |
| システムとして、メールを送信したい。 | 会員として、予約確認メールが欲しい。なぜなら、クラスの記録を残せるからだ。 |
| ユーザーとして、サイトを速くしてほしい。 | モバイルユーザーとして、時間割が2秒以内に表示されてほしい。なぜなら、外出先で予約できるからだ。 |
| 管理者として、15種類のレポートを備えたレポートモジュールが欲しい。 | ジムのマネージャーとして、クラスごとの週間出席者数を確認したい。なぜなら、時間割を調整できるからだ。 |
完全な例： 会員として、クラスが満員のときにキャンセル待ちリストに登録したい。なぜなら、誰かがキャンセルしたときに枠を確保できるからだ。 受け入れ基準： 「キャンセル待ちに登録」ボタンはクラスが満員のときにのみ表示される。会員は自分の順番を確認できる。枠が空いたら、先頭の人にメールで案内が届き、2時間以内に承諾できる。
よくある間違い
- 技術的なタスクをストーリーに見せかけて書く。
- 複数のスプリントにまたがるほど大きなストーリー。これらは エピック として扱い、分割する。
- 「なぜなら」の部分がなく、本当のニーズが見えない。
- 会話のきっかけとせず、ストーリーを契約書のように扱う。
- 受け入れ基準がない、または曖昧で、手戻りにつながる。
- 平易な一文のほうがわかりやすい場合でも、すべてのストーリーをテンプレートで書く。
このトピックの無料テンプレート
よくある質問
アジャイルにおけるユーザーストーリーとは？
ユーザーの視点で書かれたユーザーのニーズの短い説明で、チームはこれを動く機能に変えます。
ユーザーストーリーの形式とは？
［ユーザーの種類］として、［ゴール］したい。なぜなら、［便益］からだ。
ユーザーストーリーは誰が書きますか？
誰でも書けますが、ストーリーが明確で、バックログ内で適切に並べられていることへの責任は通常プロダクトオーナーが負います。
ユーザーストーリーはスクラムの一部ですか？
いいえ。スクラムガイドではプロダクトバックログアイテムについて述べています。ユーザーストーリーはそれを書くための一般的な方法です。
ユーザーストーリーにおける受け入れ基準とは何ですか？
ストーリーが受け入れられるために満たすべき具体的でテスト可能な条件。チェックリストやGiven-When-Then形式で書かれることが多いです。
ユーザーストーリーはどのくらい小さくすべきですか？
1スプリント内、理想的には数日で完了できる程度の小ささです。
ユーザーストーリーにおけるINVESTとは何の略ですか？
Independent（独立している）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積り可能）、Small（小さい）、Testable（テスト可能）。
ユーザーストーリーと要求事項の違いは何ですか？
従来の要求事項はシステムが行うべきことを詳細に規定しますが、ユーザーストーリーはニーズを記述し、会話を通じて詳細に合意することを促します。参考： プロジェクトの要求事項.
ユーザーストーリーとエピックの違いは何ですか？
なお、 エピック は多くのストーリーで構成される大きな作業のまとまりであり、ストーリーは1スプリントに収まります。
ユーザーストーリーはどのように見積もりますか？
多くのチームは、次のような相対見積りを使います： ストーリーポイント やTシャツサイズを使い、チーム全体で合意します。
ユーザーストーリーはソフトウェア以外でも使えますか？
はい。マーケティングなどのチームも「見込み客として、料金比較が欲しい。なぜなら、プランを選べるからだ」といったストーリーを書きます。参考： アジャイルマーケティング.