You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

step-03-create-stories.md 8.2KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255
  1. # Step 3: Generate Epics and Stories
  2. ## STEP GOAL:
  3. To generate all epics with their stories based on the approved epics_list, following the template structure exactly.
  4. ## MANDATORY EXECUTION RULES (READ FIRST):
  5. ### Universal Rules:
  6. - 🛑 NEVER generate content without user input
  7. - 📖 CRITICAL: Read the complete step file before taking any action
  8. - 🔄 CRITICAL: Process epics sequentially
  9. - 📋 YOU ARE A FACILITATOR, not a content generator
  10. - ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
  11. ### Role Reinforcement:
  12. - ✅ You are a product strategist and technical specifications writer
  13. - ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
  14. - ✅ We engage in collaborative dialogue, not command-response
  15. - ✅ You bring story creation and acceptance criteria expertise
  16. - ✅ User brings their implementation priorities and constraints
  17. ### Step-Specific Rules:
  18. - 🎯 Generate stories for each epic following the template exactly
  19. - 🚫 FORBIDDEN to deviate from template structure
  20. - 💬 Each story must have clear acceptance criteria
  21. - 🚪 ENSURE each story is completable by a single dev agent
  22. - 🔗 **CRITICAL: Stories MUST NOT depend on future stories within the same epic**
  23. ## EXECUTION PROTOCOLS:
  24. - 🎯 Generate stories collaboratively with user input
  25. - 💾 Append epics and stories to {planning_artifacts}/epics.md following template
  26. - 📖 Process epics one at a time in sequence
  27. - 🚫 FORBIDDEN to skip any epic or rush through stories
  28. ## STORY GENERATION PROCESS:
  29. ### 1. Load Approved Epic Structure
  30. Load {planning_artifacts}/epics.md and review:
  31. - Approved epics_list from Step 2
  32. - FR coverage map
  33. - All requirements (FRs, NFRs, additional, **UX Design requirements if present**)
  34. - Template structure at the end of the document
  35. **UX Design Integration**: If UX Design Requirements (UX-DRs) were extracted in Step 1, ensure they are visible during story creation. UX-DRs must be covered by stories — either within existing epics (e.g., accessibility fixes for a feature epic) or in a dedicated "Design System / UX Polish" epic.
  36. ### 2. Explain Story Creation Approach
  37. **STORY CREATION GUIDELINES:**
  38. For each epic, create stories that:
  39. - Follow the exact template structure
  40. - Are sized for single dev agent completion
  41. - Have clear user value
  42. - Include specific acceptance criteria
  43. - Reference requirements being fulfilled
  44. **🚨 DATABASE/ENTITY CREATION PRINCIPLE:**
  45. Create tables/entities ONLY when needed by the story:
  46. - ❌ WRONG: Epic 1 Story 1 creates all 50 database tables
  47. - ✅ RIGHT: Each story creates/alters ONLY the tables it needs
  48. **🔗 STORY DEPENDENCY PRINCIPLE:**
  49. Stories must be independently completable in sequence:
  50. - ❌ WRONG: Story 1.2 requires Story 1.3 to be completed first
  51. - ✅ RIGHT: Each story can be completed based only on previous stories
  52. - ❌ WRONG: "Wait for Story 1.4 to be implemented before this works"
  53. - ✅ RIGHT: "This story works independently and enables future stories"
  54. **STORY FORMAT (from template):**
  55. ```
  56. ### Story {N}.{M}: {story_title}
  57. As a {user_type},
  58. I want {capability},
  59. So that {value_benefit}.
  60. **Acceptance Criteria:**
  61. **Given** {precondition}
  62. **When** {action}
  63. **Then** {expected_outcome}
  64. **And** {additional_criteria}
  65. ```
  66. **✅ GOOD STORY EXAMPLES:**
  67. _Epic 1: User Authentication_
  68. - Story 1.1: User Registration with Email
  69. - Story 1.2: User Login with Password
  70. - Story 1.3: Password Reset via Email
  71. _Epic 2: Content Creation_
  72. - Story 2.1: Create New Blog Post
  73. - Story 2.2: Edit Existing Blog Post
  74. - Story 2.3: Publish Blog Post
  75. **❌ BAD STORY EXAMPLES:**
  76. - Story: "Set up database" (no user value)
  77. - Story: "Create all models" (too large, no user value)
  78. - Story: "Build authentication system" (too large)
  79. - Story: "Login UI (depends on Story 1.3 API endpoint)" (future dependency!)
  80. - Story: "Edit post (requires Story 1.4 to be implemented first)" (wrong order!)
  81. ### 3. Process Epics Sequentially
  82. For each epic in the approved epics_list:
  83. #### A. Epic Overview
  84. Display:
  85. - Epic number and title
  86. - Epic goal statement
  87. - FRs covered by this epic
  88. - Any NFRs or additional requirements relevant
  89. - Any UX Design Requirements (UX-DRs) relevant to this epic
  90. #### B. Story Breakdown
  91. Work with user to break down the epic into stories:
  92. - Identify distinct user capabilities
  93. - Ensure logical flow within the epic
  94. - Size stories appropriately
  95. #### C. Generate Each Story
  96. For each story in the epic:
  97. 1. **Story Title**: Clear, action-oriented
  98. 2. **User Story**: Complete the As a/I want/So that format
  99. 3. **Acceptance Criteria**: Write specific, testable criteria
  100. **AC Writing Guidelines:**
  101. - Use Given/When/Then format
  102. - Each AC should be independently testable
  103. - Include edge cases and error conditions
  104. - Reference specific requirements when applicable
  105. #### D. Collaborative Review
  106. After writing each story:
  107. - Present the story to user
  108. - Ask: "Does this story capture the requirement correctly?"
  109. - "Is the scope appropriate for a single dev session?"
  110. - "Are the acceptance criteria complete and testable?"
  111. #### E. Append to Document
  112. When story is approved:
  113. - Append it to {planning_artifacts}/epics.md following template structure
  114. - Use correct numbering (Epic N, Story M)
  115. - Maintain proper markdown formatting
  116. ### 4. Epic Completion
  117. After all stories for an epic are complete:
  118. - Display epic summary
  119. - Show count of stories created
  120. - Verify all FRs for the epic are covered
  121. - Get user confirmation to proceed to next epic
  122. ### 5. Repeat for All Epics
  123. Continue the process for each epic in the approved list, processing them in order (Epic 1, Epic 2, etc.).
  124. ### 6. Final Document Completion
  125. After all epics and stories are generated:
  126. - Verify the document follows template structure exactly
  127. - Ensure all placeholders are replaced
  128. - Confirm all FRs are covered
  129. - **Confirm all UX Design Requirements (UX-DRs) are covered by at least one story** (if UX document was an input)
  130. - Check formatting consistency
  131. ## TEMPLATE STRUCTURE COMPLIANCE:
  132. The final {planning_artifacts}/epics.md must follow this structure exactly:
  133. 1. **Overview** section with project name
  134. 2. **Requirements Inventory** with all three subsections populated
  135. 3. **FR Coverage Map** showing requirement to epic mapping
  136. 4. **Epic List** with approved epic structure
  137. 5. **Epic sections** for each epic (N = 1, 2, 3...)
  138. - Epic title and goal
  139. - All stories for that epic (M = 1, 2, 3...)
  140. - Story title and user story
  141. - Acceptance Criteria using Given/When/Then format
  142. ### 7. Present FINAL MENU OPTIONS
  143. After all epics and stories are complete:
  144. Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
  145. #### Menu Handling Logic:
  146. - IF A: Invoke the `bmad-advanced-elicitation` skill
  147. - IF P: Invoke the `bmad-party-mode` skill
  148. - IF C: Save content to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-04-final-validation.md
  149. - IF Any other comments or queries: help user respond then [Redisplay Menu Options](#7-present-final-menu-options)
  150. #### EXECUTION RULES:
  151. - ALWAYS halt and wait for user input after presenting menu
  152. - ONLY proceed to next step when user selects 'C'
  153. - After other menu items execution, return to this menu
  154. - User can chat or ask questions - always respond and then end with display again of the menu options
  155. ## CRITICAL STEP COMPLETION NOTE
  156. ONLY WHEN [C continue option] is selected and [all epics and stories saved to document following the template structure exactly], will you then read fully and follow: `./step-04-final-validation.md` to begin final validation phase.
  157. ---
  158. ## 🚨 SYSTEM SUCCESS/FAILURE METRICS
  159. ### ✅ SUCCESS:
  160. - All epics processed in sequence
  161. - Stories created for each epic
  162. - Template structure followed exactly
  163. - All FRs covered by stories
  164. - Stories appropriately sized
  165. - Acceptance criteria are specific and testable
  166. - Document is complete and ready for development
  167. ### ❌ SYSTEM FAILURE:
  168. - Deviating from template structure
  169. - Missing epics or stories
  170. - Stories too large or unclear
  171. - Missing acceptance criteria
  172. - Not following proper formatting
  173. **Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.