如何在Scrum中撰寫優秀的使用者故事

約有70%的科技專案失敗。數十年來，人們普遍認為專案失敗是因為未遵循最佳實務，或團隊缺乏所有必要的技能。然而，最佳實務、技能與能力的應用已隨著年代不斷提升——那麼為何專案仍會失敗？

考慮到有70%的軟體專案因需求不良而失敗，這些失敗所導致的重做成本每年超過450億美元。

問題在於——為何會發生這種情況？答案有兩點。首先，商業需求經常忽視客戶；其次，需求缺乏一個整體的參考架構，使得需求分析師無法從客戶需求與策略一路追蹤並驅動至所實施的解決方案。

要撰寫優良的需求或使用者故事，請遵循以下步驟：

1. 定義盡可能多的使用者角色，以代表系統的使用者。這將幫助您專注於客戶，並根據客戶需求來驅動與追蹤需求。由艾倫·庫珀提出，使用者角色定義了系統的典型使用者——即與系統互動的人的範例。使用者不一定要是或代表個人，也可以代表一個組織。
2. 確保您的使用者故事遵循「3C」原則：

• 卡片 — 應寫在索引卡或便利貼上
• 對話 — 從產品負責人取得詳細資訊
• 確認 — 確保正確實作，必須符合使用者驗收標準。

3. 將使用者故事拆分，使其大小適中，能適當地納入一個Sprint中。 一些拆分故事的方法包括：

• 依工作流程步驟拆分
• 依輸入/輸出管道拆分
• 依使用者選項拆分
• 依使用者角色拆分
• 依資料範圍拆分

4. 讓每個使用者故事都遵循INVEST記憶法：

敏捷INVEST記憶法，由比爾·沃克所創，作為確保高品質產品待辦事項（PBIs）的指引，通常以使用者故事格式撰寫。

• 獨立：故事應盡可能獨立。
• 可議價：故事不是合約。故事是對一場對話的邀請。故事捕捉了所期望內容的本質。
• 具價值: 如果一個故事沒有明顯的價值，就不應該進行。
• 可估算的: 故事必須可估算或具備規模，以便正確地進行優先排序。
• 小型: 對於兩週的迭代，使用者故事的平均工作量應為3至4天——總計！這包括將故事帶到「完成」狀態所需的所有工作。使用者故事越小，估算的準確性越高！
• 可測試的: 每個故事都必須可測試，才能被視為「完成」。

• 撰寫使用者故事的SMART目標與INVEST原則
• 主題 vs 優勢 vs 使用者故事 vs 任務
• 產品待辦事項中的DEEP代表什麼意思？
• 如何為Scrum專案撰寫產品願景？
• 如何使用Scrum看板進行敏捷開發？
• 在Scrum中，誰負責建立產品待辦事項或使用者故事？
• 什麼是敏捷估算？
• 敏捷中的故事點是什麼？如何估算使用者故事？
• 使用者故事拆分——垂直切片 vs 水平切片