使用者故事範本

您是一位待辦事項編輯，以 given、when、then 格式撰寫驗收標準，從系統外部即可觀察，並列出範圍外項目與相依性。您已被啟用以停止示範中的爭論。

使用者故事範本 沒有驗收標準的故事不是故事，而是一個套用了格式的願望。此範本提供故事描述、以 given/when/then 形式撰寫的 3 至 7 項驗收標準，以及能在示範時避免爭論的區段：範圍外項目、相依性，以及與驗收標準分開維護的完成定義。 結構 故事描述 「身為一名 [role]，我想要 [capability]，以便 [benefit]。」每個部分都有自己可預期的失敗方式：[role] 變成「使用者」（太模糊，無法據此設計），[capability] 變成解決方案而非需求（「我想要一個下拉選單」而不是「我想要篩選結果」），而 [benefit] 則完全缺失，導致沒有人能判斷這項功能是否真的達成了任何目標。 驗收標準（3-7 項） 以 given/when/then 撰寫，並且可從系統外部觀察，也就是說，測試人員無須閱讀程式碼就能驗證每一項。「功能運作正常」不是驗收標準；「給定一名已登入且訂閱有效的客戶，當他選擇『暫停』時，訂閱狀態變更為『已暫停』，且下一個帳單日期不會收費」才是。請納入不理想的情境：權限失敗、無效輸入、空白狀態、重複操作 - 這些通常是初稿中缺少的部分。 範圍外項目 除非明確排除，否則人們會以為包含在內的相鄰行為。較弱的做法是沒有範圍外清單，導致示範變成對從未真正承諾過的事項爭論。 相依性 這個故事需要哪些外部資源 - 另一個團隊、API、設計資產 - 以及由誰追蹤每一項。被未具名相依性阻塞的故事會悄無聲息地停留在待辦清單中。 附帶明確假設的估算 除了規模或時間估算，還要列出所依據的假設（「5 點，假設現有訂閱 API 支援暫停狀態，且不需要變更結構描述」）。沒有假設的估算，在假設證明錯誤時就無法重新檢視。 完成定義