本章討論幾個與 User Story 相關的延伸議題，包括非功能性需求的處理、紙卡與軟體的選擇、使用者介面設計、Story 的保留，以及 Bug 的處理。

處理非功能性需求#

並非所有需求都能寫成 User Story。非功能性需求（如效能、安全性、可維護性等）通常以約束條件（Constraint）的形式處理。

常見的非功能性需求類型：

將約束條件寫在獨立的卡片上，標註為「Constraint」。大多數約束條件可以撰寫自動化測試來驗證合規性。

紙卡還是軟體#

這是一個常見的辯論。兩種方式各有優勢：

紙卡的優勢#

• 簡單直觀：低科技的提醒，Story 本就是不精確的
• 促進互動：可以在桌上排列、堆疊、分類
• 有限的空間：自然限制了 Story 的細節量

軟體的優勢#

• 追溯性：容易滿足 ISO 等認證的追溯需求
• 遠端協作：分散式團隊必須使用軟體
• 排序靈活：容易進行多維度的排序和篩選

作者建議從紙卡開始，觀察在你的環境中如何運作。如果有充分理由（遠端團隊、合規需求），再切換到軟體。

User Story 與使用者介面#

敏捷方法主張迭代式開發，但使用者介面的頻繁變動可能會困擾使用者。Larry Constantine 指出：

對使用者介面而言，架構、導覽和整體外觀必須在一開始就設計好，後續的迭代式精煉是不可接受的。

如果 UI 對產品成功至關重要，考慮採用 Agile Usage-Centered Design 的流程：

1. 進行使用者角色建模
2. 蒐集高層級 Story
3. 排定優先順序
4. 精煉高優先和中優先的 Story
5. 將 Story 分組
6. 建立紙本原型
7. 精煉原型
8. 開始開發

如果你的產品有重要的 UI，不要完全依賴迭代來「長出」好的介面。在開發前投入幾天到幾週做 UI 原型是值得的。

保留還是丟棄 Story#

Story 完成開發後是否應該保留？作者建議保留：

• 如果使用軟體工具，沒有理由刪除已完成的 Story
• 如果使用紙卡，可以存檔或影印保留
• 在公司被收購、產品改寫、需要展示流程等情境中，保留的 Story 都可能派上用場

Bug 的處理#

Bug 和 Story 的關係取決於 Bug 的大小：

• 大型 Bug（修復時間與一般 Story 相當）：當作獨立的 Story 處理
• 小型 Bug（預期可快速修復）：多個小 Bug 釘在一起，加上一張封面卡片，當作一個 Story 處理

有些團隊使用不同顏色的卡片來區分 Story 類型（白色=正常、紅色=Bug、藍色=技術任務）。但作者認為這增加了不必要的複雜性——簡單地使用白色卡片就好。