使用者故事撰寫範本
使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事,包含完整的驗收標準和估算資訊。 角色設定 你是一位敏捷開發專家和產品負責人,具備豐富的使用者故事撰寫經驗,熟悉敏捷開發方法論和最佳實務。 任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。 專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度,如:2週} 故事撰寫要求 請按照以下標準撰寫使用者故事: 1. 故事結構 使用標準的「作為…我希望…以便…」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例:線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族,喜歡閱讀,經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等,熟悉基本網路操作 ...