受け入れ基準付きのユーザーストーリーテンプレート（無料）

ユーザーストーリーテンプレートには2つの役割があります。一つ目は、すべてのストーリーが同じ3つの質問（誰が、何を、なぜ）に答えるようにすること。二つ目は、チームがストーリーの完了判定基準を記述するための固定された場所を提供することです。このページでは、1行フォーマット、コピー可能な完全なカードテンプレート、3つの形式の受け入れ基準、「準備完了」と「完了」の定義、そして実例を提供します。

ユーザーストーリーが初めての方は、まず ユーザーストーリーの書き方のガイドから始めて、その後、このテンプレートに戻ってください。

1行のユーザーストーリーテンプレート

ほとんどのチームは、2001年にロンドンのConnextraチームで生まれたフォーマットを使用しており、Mike Cohnの著書『User Stories Applied』で広く知られるようになりました（ユーザーストーリーの概要 は良い入門書です）：

私は[ユーザータイプ]として、[アクションまたは機能]をしたいので、[利益または結果]が得られる。

各部分には特定の役割があります：

• 「私は」は、初回購入者、アカウント管理者、リピーター患者など、具体的なユーザーの種類を指します。「ユーザーとして」ではチームは何も得られません。ペルソナがある場合は、その名前を使用してください。
• 「～したい」は、ユーザーが何をするか、または何を得るか、ユーザーの言葉で記述します。解決策（「ドロップダウン」「Redisキャッシュ」など）を記述せず、チームが最適な方法を見つける余地を残してください。
• 「～ので」は価値を記述します。これは最も省略されがちで、最も重要な部分です。チームが同じ結果をもたらすよりシンプルな案を提案したり、プロダクトオーナーが優先順位を決定したりするための基準になります。

この文は要件そのものではありません。Ron Jeffriesは、ストーリーをカード、会話、確認の3つの要素と定義しました（3Cs）。テンプレートはカードと確認（受け入れ基準）の作成に役立ちますが、会話に代わるものはありません。

完全なユーザーストーリーカードテンプレート

1行フォーマットは付箋には十分ですが、バックログツールでは、ストーリーをランキング、見積もり、テストするためにいくつかの追加フィールドが必要です。以下は有用なフィールドですが、チームが読まないものは削除してください。

「コンテキストとメモ」は簡潔に保ってください。仕様書1ページ分になるほど、そのストーリーはおそらくエピックであり、分割が必要です（私たちの ストーリーマッピングガイド で方法を確認できます）。

そのまま使えるユーザーストーリーテンプレート

これをJiraやLinearのチケットの説明欄、Notionのデータベーステンプレート、またはスプレッドシートのヘッダー行に貼り付けてください。角括弧内のテキストを置き換え、使用しない行は削除してください。

• ID: [PROJECT-000]
• タイトル: [動詞 + 目的語、例: 「請求書をCSVにエクスポート」]
• ストーリー: [ユーザータイプ] として、[アクションまたは機能] を行いたいので、[利益] が得られる。
• コンテキスト: [なぜ今これが重要なのか。リサーチ、サポートチケット、またはメトリクスへのリンク]
• 受け入れ基準: [チェックリストまたはGiven/When/Then形式で、テスト可能な条件を3〜7個]
• スコープ外: [このストーリーが意図的にカバーしないもの]
• デザイン: [フレームまたはプロトタイプへのリンク]
• 依存関係: [他のストーリー、サービス、または意思決定]
• 優先度: [Must / Should / Could、またはバックログ順位]
• 見積もり: [ポイントまたはサイズ、チームが記入]
• 未解決の質問: [スプリント開始前に回答が必要な事項]

「スコープ外」の記載は議論を防ぎます。カードに「SMSによるリセットは含まない」と書くことは、スプリントレビューで誰かがそれが含まれると想定していたと発覚するよりも効果的です。

受け入れ基準とは何か、誰がそれを書くか

受け入れ基準とは、プロダクトオーナーがストーリーを受け入れるために満たすべき条件です。コードの動作方法ではなく、ユーザーの視点から観察可能な振る舞いを記述します。良い基準は以下の通りです：

• テスト可能: 解釈なしで「はい」または「いいえ」と答えられること。「速い」はテスト可能ではありませんが、「2秒以内に結果が表示される」はテスト可能です。
• このストーリーに固有: すべてのストーリーに適用されるルール（コードレビュー済み、ステージング環境にデプロイ済みなど）は、完了の定義に属し、ここには記載しません。
• 実装詳細を含まない: 何が起きるかを書き、どのコンポーネントやテーブルがそれを可能にするかまでは書きません。
• 失敗時の正直さ: 少なくとも1つの基準で、無効な入力、ネットワークなし、権限不足などのケースをカバーすること。
• 少数: 3〜7個の基準が健全な範囲です。10個を超えると、通常はストーリーを分割すべきことを示唆します。

基準に対する責任はプロダクトオーナーが負いますが、一人で書くべきではありません。最も信頼できるパターンは、プロダクト、開発者、テスター（しばしば「3人の友人」と呼ばれる）による短いリファインメント会話です：価値は何か、どのように構築されるか、どのように壊れる可能性があるか。

形式1: チェックリスト形式の受け入れ基準

条件の単純なリストです。書きやすく読みやすく、単純なストーリーや手動テストを行うチームに適しています。

ストーリー: 既存の顧客として、メールでパスワードをリセットしたいので、サポートに連絡せずにアカウントにアクセスできるようになる。

• ログイン画面に「パスワードをお忘れですか？」リンクがあり、リセットフォームを開く。
• 登録済みのメールアドレスを送信すると、1分以内にリセットリンクが届く。
• リセットリンクは1回のみ有効で、30分後に期限切れになる。
• 新しいパスワードは既存のパスワードルールを満たす必要があり、フォームはどのルールに違反したかを表示する。
• リセットが成功すると、そのアカウントの他のすべてのセッションがログアウトされます。
• 未登録のアドレスを送信しても、登録済みアドレスの場合と同じ確認メッセージが表示されるため、フォームから誰がアカウントを持っているかは判別できません。

動作が単純な場合はチェックリストを使用してください。その弱点は、開始状態とイベントの順序を隠してしまう点ですが、次の形式ではこれらを明示します。

形式2: Given/When/Then (Gherkin) による受け入れ基準

Given/When/Thenは、Dan NorthがChris Mattsと著書 Introducing BDDで説明した、振る舞い駆動開発（BDD）に由来します。各シナリオは、開始コンテキスト（Given）、アクション（When）、期待される結果（Then）を記述します。 Gherkin は、Cucumberなどのツールで使用されるこの言語の構造化されたバージョンであり、このように記述されたシナリオは、わずかな言い換えだけで自動テストに変換できます。

以下は、パスワードリセットのストーリーを3つのシナリオとして示したものです。2つのエラーパス（不幸な経路）を含みます。

シナリオ1: 有効なリンクでのリセット

• 前提: anna@example.comにアカウントが登録されていること
• かつ、パスワードリセットをリクエストしていること
• 実行: 30分以内にリセットリンクを開き、ルールを満たす新しいパスワードを入力すること
• 結果: パスワードが変更されること
• かつ、ログイン状態になること
• かつ、他のセッションがログアウトされること

シナリオ2: リンクが期限切れの場合

• 前提: 30分以上前にパスワードリセットをリクエストしたこと
• When リセットリンクを開く
• Then リンクが期限切れになったというメッセージが表示される
• かつ、新しいリンクを送信するボタンが提示されていること

シナリオ3: メールアドレスが未登録の場合

• 前提: sam@example.comのアカウントが存在しないこと
• 実行: sam@example.comでパスワードリセットをリクエストすること
• 結果: 登録済みユーザーが見るのと同じ確認メッセージが表示されること
• かつ、メールが送信されないこと

1つのシナリオを複数の入力値（例えば、拒否されるべきパスワードのリストなど）で実行する必要がある場合、Gherkinのシナリオアウトライン（Scenario Outline）を使用すると、一度だけ記述し、入力値を例のテーブルに列挙できます。

Gherkinは読みやすく保ちましょう。1シナリオ1動作とし、宣言的に記述（「リセットリンクをリクエストしたとき」など）し、クリック単位で記述（「送信ボタンをクリックしたとき」など）しないようにすることで、リデザイン後もシナリオが有効なまま維持できます。

形式3: ルールベースの受け入れ基準

主にビジネスルール（価格設定、適用条件、検証、権限など）に関するストーリーでは、ルールを直接記述し、複雑な組み合わせのみシナリオを追加してください。

ストーリー: 購入者として、チェックアウト時に割引コードを適用したい。これにより、プロモーション価格を支払える。

• ルール1: 1注文につき1コード。
• ルール2: パーセンテージコードは、送料や税金ではなく、製品小計にのみ適用される。
• ルール3: 最低購入金額が設定されたコードは、割引前の小計が最低金額を満たす場合にのみ適用される。
• ルール4: 期限切れまたは使用済みコードは、理由を明記したメッセージとともに拒否される。
• ルール5: 項目を削除して小計が最低金額を下回ると、コードが削除され、通知が表示される。

1つのストーリーで複数の形式を組み合わせることができます。一般的なパターンは、ロジックにはルール形式を、誤読されやすいケースには2〜3つのGiven/When/Thenシナリオを使用することです。

Definition of Ready と Definition of Done

受け入れ基準は1つのストーリーに固有です。Definition of Ready と Definition of Done は、すべてのストーリーに適用されるチーム全体の合意事項です。

The Scrum Guide Definition of Done を、インクリメントが製品に要求される品質基準を満たした状態の正式な記述として定義しています。Definition of Ready は Scrum の一部ではなく、半ば理解されたままの作業がスプリントに入るのを防ぐために多くのチームが採用しているプラクティスです（ Definition of Ready そして 完了の定義).

Definition of Ready の例

• ストーリーはテンプレートに従っており、「so that」が記入されている。
• 受け入れ基準は、プロダクト、開発、テストによって作成・レビューされている。
• デザインがリンクされているか、チームが不要と合意している。
• 依存関係が完了しているか、スケジュールされている。
• チームが見積もりを行っており、1つのスプリントに収まる。

Definition of Done の例

• すべての受け入れ基準が合格している。
• コードがレビューされ、メインブランチにマージされている。
• 自動化テストが新しい動作をカバーし、全テストスイートが合格している。
• 基本的なアクセシビリティチェックに合格（キーボード操作、ラベル、コントラスト）。
• ステージング環境にデプロイされ、プロダクトオーナーが承認済み。

「準備完了の定義」は、ゲート（通過点）ではなく、リファインメントのためのチェックリストとして扱うこと。もしチームが、チェックリストの1つでも満たさないストーリーをすべて拒否すれば、作業は停滞し、そのストーリーが本来引き起こすはずの対話も起こらなくなる。

実例

異なる種類の製品から2つのストーリーを追加。残り40件については、こちらを参照 ユーザー・ストーリーの例.

SaaS：チームメンバーを招待する（チェックリスト）

ワークスペース管理者として、メールでチームメンバーを招待したい。これにより、自分のログイン情報を共有せずに、彼らがプロジェクトを確認できるようにするため。

• 管理者はメンバーページに「招待」ボタンを表示されるが、他のロールには表示されない。
• 管理者は送信前にロール（メンバーまたは管理者）を選択できる。
• 招待メールは1分以内に届き、リンクの有効期限は7日間。
• すでにメンバーであるアドレスを招待すると、2回目の招待を送信する代わりにメッセージが表示される。

Eコマース：商品を後で保存する（Given/When/Then形式）

購入の準備ができていない購入者として、カート内の商品を保存リストに移動したい。これにより、注文合計に影響させずに、後でその商品を見つけられるようにするため。

• 前提：ログイン済みで、カートに2つの商品がある場合
• 実行：1つの商品で「後で保存」を選択した場合
• 結果：その商品が保存リストに移動する
• かつ、カート合計がその商品を含まないよう再計算される
• 前提：ログインしていない場合
• 実行：「後で保存」を選択した場合
• 結果：ログインを促され、ログイン後にその商品が保存される

Jira、Linear、Notion、またはスプレッドシートでのテンプレートの活用

Jiraでは、Storyイシュータイプを使用し、テンプレートを説明欄に貼り付ける（管理者が専用フィールドを追加している場合は、そこに受け入れ基準を記述する）。Linearでは、イシューテンプレートとして保存する。Notionでは、データベーステンプレートに設定し、新しいバックログページが事前入力状態で開くようにする。スプレッドシートは1行1ストーリーで、最初のバックログ作成やワークショップには適しているが、複数人が編集する場合はトラッカーに移行する。ツールは問わず、テンプレートは人が記入しやすい短さに保つこと。

AIを用いたストーリーと受け入れ基準のドラフト作成

言語モデルは、ストーリーや基準の初稿作成に優れている。有効なプロンプトの例：

あなたはプロダクトマネージャーです。以下の機能について、「[ユーザー]として、[アクション]をしたい。その理由は[利益]」という形式でユーザーストーリーを作成してください。各ストーリーには、Given/When/Then形式で3〜6個の受け入れ基準を追加し、少なくとも1つの unhappy path（エラー/例外ケース）を含めてください。仮定事項と未解決の質問は別途リストアップしてください。機能：[機能、ユーザー、制約事項を記述]。

その後、他の入力と同様にドラフトをレビューする：

• そのユーザーは、実際に話したことがある具体的なセグメントか、それとも一般的な「ユーザー」か？
• モデルがビジネスルール、制限、数値を捏造していないか？それらは自社のものに置き換えること。
• unhappy pathは、ユーザーが実際に遭遇するものか？ドラフトは、リファインメントの対話を代替できない。

よくある質問

ストーリーを動作するソフトウェアに変えるチームが必要ですか？バックログ、あるいはアイデアだけでも持ち込んでください。スプリントサイズのストーリーに形作り、構築するお手伝いをします。詳細は 月額開発プラン.