deliver-user-stories

ユーザーストーリー

ユーザーストーリーとは、ユーザーの視点から機能を簡潔に説明したものです。誰が何を必要としていて、その理由は何かを捉えますが、構築方法は指定しません。優れたユーザーストーリーがあれば、ユーザー価値を重視しながら、大規模な機能を見積もり可能で提供可能な単位に分割できます。

使用する場合

• PRD の承認後、実装に向けて機能を分解するとき
• スプリント計画で、実行可能な作業項目を作成するとき
• エンジニアリングチーム向けのチケットを作成するとき
• 関係者に要件をわかりやすく伝えるとき
• ユーザー価値に基づいてバックログの優先順位を決めるとき

使用しない場合

• 単一のストーリーやスライスについて、より詳細で QA にすぐ使える Given/When/Then 形式のカバレッジが必要な場合 -> deliver-acceptance-criteria を使用してください
• 機能全体にわたる境界条件と失敗シナリオのカタログが必要な場合 -> deliver-edge-cases を使用してください
• 機能自体がまだ定義されていない場合 -> まず deliver-prd を使用してください。ストーリーは文書化された要件にさかのぼれる必要があります
• リファインメントセッションの成果（見積もり、スコープの決定、未解決の質問）が必要な場合 -> iterate-refinement-notes を使用してください

手順

ユーザーストーリーの作成を依頼されたら、次の手順に従ってください。

1. 機能の背景を理解する PRD または機能の説明を確認します。全体的な目標、対象ユーザー、スコープの境界を理解してください。ユーザーストーリーは文書化された要件にさかのぼれる必要があります。

2. ユーザーペルソナを特定する この機能を利用するユーザーを特定します。各ストーリーは、一般的な「ユーザー」ではなく、具体的なペルソナを対象に記述してください。同じ機能でも、ペルソナによって必要なストーリーが異なる場合があります。

3. ユーザーの目標ごとに分解する 機能を、個別のユーザー目標に分解します。各ストーリーでは、完全で価値のある機能、つまりストーリーの完了後にユーザーが実際にできることを提供する必要があります。

4. ストーリーを記述する 次の形式を使用します。「[ペルソナ]として、[メリット]のために[アクション]したい。」メリットの節は重要です。なぜ重要なのかを説明し、優先順位付けに役立ちます。

5. 受け入れ条件を定義する Given/When/Then 形式を使用して、具体的でテスト可能な条件を記述します。受け入れ条件によって「完了」が定義されます。すべての条件に合格すれば、そのストーリーは完了です。

6. INVEST 基準を適用する 各ストーリーを、INVEST（独立性、交渉可能性、価値、見積もり可能性、小ささ、テスト可能性）に照らして確認します。基準を満たさないストーリーは修正してください。

7. 背景情報と注記を追加する 関連するデザイン資料、技術的な考慮事項、依存関係を記載します。これらは実装担当者が全体像を理解するのに役立ちます。

出力形式

references/TEMPLATE.md のテンプレートを使用して出力を構成してください。完全な出力では、各ストーリーに次の項目を含めます。ストーリーヘッダー、ユーザーストーリーの記述、背景と経緯、受け入れ条件、デザイン上の注記、技術的な注記、依存関係、対象範囲外、未解決の質問（残っている場合）。複数のストーリーを含む文書では、例に示すように、ストーリーごとに 1 つの見出しを設け、その下にこれらの項目を配置します。

品質チェックリスト

最終化する前に、次の点を確認してください。

• 各ストーリーが「〜として、〜したい。〜のため。」の形式に従っている
• ストーリーが独立している（任意の順序で実装できる）
• 受け入れ条件が Given/When/Then 形式で記述されている
• 各条件がテスト可能である（合格か不合格かを確認できる）
• 各ストーリーが 1 スプリントで完了できる規模である
• ストーリーの記述に実装の詳細が含まれていない
• メリットの節で、ユーザーにとってなぜ重要なのかを説明している

例

完成例については、references/EXAMPLE.md を参照してください。