使用者故事撰寫範本
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歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作
使用者故事範例
故事ID: US001 故事標題: 將書籍加入購物車
使用者故事: 作為 線上購書者 我希望 能夠將感興趣的書籍加入購物車 以便 可以一次購買多本書籍並比較選擇
驗收標準:
場景1: 成功加入購物車 Given 我正在瀏覽書籍詳細頁面 When 我點擊「加入購物車」按鈕 Then 書籍被成功加入購物車 And 購物車圖示顯示更新的商品數量 And 顯示確認訊息「已加入購物車」
場景2: 重複加入相同書籍 Given 購物車中已有某本書籍 When 我再次嘗試加入相同書籍 Then 購物車中該書籍的數量增加1 And 顯示「數量已更新」訊息
故事點數: 3 點 優先級: 高
常見問題與解決方案
Q1: 故事太大怎麼辦？
解決方案: 使用故事拆分技巧，將大故事分解為多個小故事
Q2: 如何處理技術性故事？
解決方案: 將技術工作包裝成對使用者有價值的功能描述
Q3: 驗收標準寫得太詳細？
解決方案: 專注於核心行為和結果，避免實作細節
Q4: 如何估算故事點數？
解決方案: 使用規劃撲克，比較相對複雜度而非絕對時間
注意事項
- 保持故事的使用者導向，避免技術術語
- 確保每個故事都有明確的商業價值
- 驗收標準要具體且可測試
- 考慮不同裝置和瀏覽器的相容性
- 包含無障礙設計的考量
- 定期回顧和更新故事內容