本章列出常見的 Story「壞味道」（Bad Smells）——這些跡象暗示 Story 的使用方式出了問題。每個壞味道都附有症狀描述和建議的解決方案。
Story 太小#
症狀：需要頻繁修正估算。
小 Story 的估算容易因為實作順序不同而大幅波動。例如「搜尋結果可以存成 XML 檔案」和「搜尋結果可以存成 HTML 檔案」這兩個 Story，先做哪個會影響後做的那個的工作量。
將這類高度重疊的小 Story 合併為一個。等到進入迭代時再拆分即可。
Story 之間相互依賴#
症狀：規劃迭代時很困難，因為 Story 之間有依賴關係。
當一個 Story 只能在另一個 Story 完成後才能進入迭代，排程就變得複雜。
解決方案：
- 嘗試將相依的 Story 合併
- 重新拆分 Story，讓每個 Story 都是完整的「蛋糕切片」
鍍金（Goldplating）#
症狀：開發人員在加入未被規劃的功能，或過度解讀 Story。
Goldplating 指的是開發人員添加非必要的功能。這可能出於以下原因：
- 想給客戶「驚喜」
- 在短迭代中感受到持續產出的壓力
- 享受在程式碼上留下自己的印記
解決方案：
- 透過每日站會增加工作的透明度
- 在迭代檢視會議中展示所有新功能，讓非計畫中的工作無所遁形
- 如果開發人員有好點子，應建議客戶將其加入 Product Backlog
太多細節#
症狀：花費大量時間預先蒐集細節，或花更多時間寫 Story 而非討論 Story。
Story 應寫在小卡片上，空間有限。如果寫不下，表示細節太多了。
Tom Poppendieck 建議：「如果卡片空間不夠，用更小的卡片。」
過早包含 UI 細節#
症狀：專案早期的 Story 就包含具體的 UI 描述。
在專案初期就指定 UI 會限制設計空間。
解決方案：
- 不好：「A Job Seeker can view information about the hiring company from the Job Description page.」
- 好：「When viewing details about a job, a Job Seeker may view information about the hiring company.」
想太遠#
症狀：Story 寫不進卡片、有人提議使用 Story 模板、建議用更細的單位估算。
這個壞味道常見於習慣大量前期「需求工程」的團隊。
使用 Story 的根本認知是：對大多數問題而言，不可能預先識別所有需求。好的軟體是透過多次迭代，逐步增加細節而產生的。
拆分太多 Story#
症狀：在迭代規劃中頻繁拆分 Story。
偶爾拆分 Story 是正常的，但如果頻繁發生，可能需要在規劃前先主動檢視並拆分過大的 Story。
客戶難以排定優先順序#
症狀：客戶在排定 Story 優先順序時遇到困難。
可能的原因：
- Story 太大：讓客戶難以取捨，應拆分為更小的 Story
- Story 缺乏商業價值描述：技術導向的 Story（如「建立連線池」）讓客戶無法判斷價值
- Story 數量太少但每個太大：客戶只有幾個巨大的 Story 可選，無法精細調整
客戶不願意撰寫和排序 Story#
症狀：客戶不願承擔撰寫或排序 Story 的責任。
在推卸責任的組織文化中，客戶可能因為害怕「做錯決定」而迴避。
找到方法讓客戶安心地表達意見。如果有多位客戶，告訴他們你在蒐集各方意見，但最終決策的責任在你。