INVEST 原則#
Bill Wake 提出了好 Story 的六個準則，縮寫為 INVEST：
- Independent（獨立的）
- Negotiable（可協商的）
- Valuable（有價值的）
- Estimable（可估算的）
- Small（大小適中的）
- Testable（可測試的）
Independent：獨立的#
Story 之間應盡量避免相互依賴。依賴關係會讓排定優先順序和迭代規劃變得困難，因為一個 Story 的排程會牽動另一個。
當兩個 Story 有依賴關係時，嘗試：（1）將它們合併為一個 Story；或（2）用不同的方式拆分，使依賴消失。
Negotiable：可協商的#
Story 不是合約，而是對話的邀請。Story 卡片上的文字只是提醒，細節應在開發前透過對話來確定。
如果 Story 被當成不可更改的需求規格書，就失去了敏捷的核心精神——擁抱變化。
Valuable：有價值的#
每個 Story 都必須對客戶或使用者有明確的價值。以下是常見的錯誤：
- 「建立資料庫連線池」——這是技術任務，不是 Story
- 「撰寫 API 文件」——對使用者沒有直接價值
Story 應該穿越系統的所有層級（就像一塊「蛋糕切片」），而非只處理某一層（如只做資料庫或只做 UI）。這樣每個 Story 完成後都能為使用者帶來實際可用的功能。
Estimable：可估算的#
開發人員必須能夠估算 Story 的大小。無法估算通常代表：
- 對領域不了解：需要進行探索性工作（Spike）
- Story 太大：需要拆分
- Story 太模糊：需要與客戶進一步討論
Small：大小適中的#
Story 不應太大也不應太小：
- 太大（Epic）：難以估算，無法在一個迭代內完成
- 太小：不值得單獨追蹤和管理，容易被忽略
一般而言，一個迭代內應安排 5-15 個 Story。若 Story 過大，按照前面介紹的技巧拆分。
Testable：可測試的#
Story 必須能夠被驗證。如果寫不出驗收測試，表示 Story 描述不夠具體。
- 不可測試：「使用者覺得軟體好用」
- 可測試：「使用者可以在 30 秒內完成搜尋和下單」
非功能性需求（如「系統必須很快」）也需要轉化為可測試的約束條件（如「80% 的搜尋回應時間 < 2 秒」）。