Scrum 對需求的處理方式與傳統開發截然不同。本章介紹 Scrum 如何以**對話（Conversation）和漸進精煉（Progressive Refinement）**取代厚重的前期需求文件，並深入探討 User Story 作為產品待辦項目（PBI）的主流表述格式。

需求觀念的根本轉變#

傳統做法 vs. Scrum#

在 Scrum 中，需求是重要的自由度：時間或預算不足時可以丟棄低價值需求；開發中發現成本效益比惡化時可以移除需求；出現高價值的新需求時可以加入。

我們不會在前期花大量時間與金錢把需求細節全部釐清，而是建立佔位符（placeholder）稱為產品待辦項目（Product Backlog Items, PBIs）。初期 PBI 較大且細節少，隨時間透過利害關係人、Product Owner 與開發團隊之間的對話，逐步精煉為更小、更詳細的項目，最終小到足以進入 Sprint 設計、開發與測試。

以對話驅動需求（Using Conversations）#

順序式開發依賴書面需求，看起來很厲害，但極易產生誤解。Scrum 把對話作為確保需求被正確討論與溝通的關鍵工具。

口頭溝通的優勢：

• 高頻寬：能傳遞的資訊量遠大於文件
• 快速回饋：即時確認理解是否一致
• 雙向溝通：能激發對問題與機會的討論，這在單純閱讀文件時不會發生

對話不是要取代所有文件。Product Backlog 本身就是一份在整個開發期間隨時可用的「活文件」。如果仍然需要需求規格文件，隨時可以將 PBI 及其細節彙整成任何格式的文件。

漸進精煉（Progressive Refinement）#

傳統做法要求所有需求在同一時間達到同等細節層級，這導致：

• 在知識最少的時候就必須預測所有細節
• 不論優先級高低，對所有需求投入相同資源
• 建立龐大的需求庫存，變更時極為昂貴
• 因為需求已「完整」，降低了用對話來釐清的可能性

Scrum 採用漸進精煉策略：即將開發的需求較小且詳細，遠期的需求較大且概略。以即時（just-in-time）的方式將大型、輕量細節的需求拆解為一組更小、更詳細的項目。

什麼是 User Story？#

User Story 是表達期望商業價值的便利格式，具有以下特點：

• 商業人員與技術人員都能理解
• 結構簡單，提供對話的好起點
• 可用不同粒度撰寫
• 容易漸進精煉

Ron Jeffries 用三個 C 來描述 User Story：Card、Conversation、Confirmation。

Card（卡片）#

常用的 User Story 模板：

As a <user role> I want to <goal> so that <benefit>.

例如：

As a typical user I want to see unbiased reviews of a restaurant near an address so that I can decide where to go for dinner.

卡片刻意使用小尺寸以促進簡潔。幾句話捕捉需求的本質或意圖即可——它是更詳細討論的佔位符，不是要記錄所有資訊。

Conversation（對話）#

需求的細節透過開發團隊、Product Owner 與利害關係人之間的對話來揭露與溝通。User Story 本質上是一個進行對話的承諾。

對話不是一次性事件，而是持續的對話：

1. 撰寫 User Story 時
2. 精煉時
3. 估算時
4. Sprint Planning 深入任務層級時
5. Sprint 期間設計、開發、測試時

flowchart LR
    A[撰寫 Story] --> B[精煉 Story]
    B --> C[估算 Story]
    C --> D[Sprint Planning\n拆解任務]
    D --> E[Sprint 執行\n設計/開發/測試]

    style A fill:#e1f5fe
    style E fill:#e8f5e9

User Story 可以也應該附加任何有助於釐清需求的書面資料。例如某醫學影像團隊的 Story 引用了一篇完整的期刊文章作為未來討論的參考。

Confirmation（確認）#

User Story 包含**滿足條件（Conditions of Satisfaction）**作為驗收標準，用來：

• 讓開發團隊理解該建什麼、該測什麼
• 讓 Product Owner 確認實作是否符合期望

這些條件可以表達為高階驗收測試。例如「Upload File」Story 的滿足條件：

• 驗證 .txt 和 .doc 檔案
• 驗證 .jpg、.gif 和 .png 檔案
• 驗證 .mp4 檔案 <= 1 GB
• 驗證無 DRM 限制檔案

規格化範例（Specification by Example） 或 驗收測試驅動開發（ATTD）：透過定義具體範例與期望行為來驅動 Story 的建立與精煉，並自動產生驗收測試。

flowchart LR
    A["Card\n卡片"] -->|"觸發"| B["Conversation\n對話"]
    B -->|"產出"| C["Confirmation\n確認"]
    C -->|"回饋修正"| A

    A -.- A1["簡短描述\n作為佔位符"]
    B -.- B1["持續對話\n揭露細節"]
    C -.- C1["驗收條件\n規格化範例"]

抽象層級（Level of Detail）#

User Story 可以在不同抽象層級撰寫：

Epic（史詩）#

• 大小：數月，可能跨越整個 Release 或多個 Release
• 用途：提供高層次的全貌概覽，作為大量更細節 Story 的佔位符
• 不會直接放進 Sprint 開發，因為太大且細節不足

Feature（功能）#

• 大小：通常以週計，大於單一 Sprint
• 是 Epic 與可實作 Story 之間的中間層級

Story（故事）/ Sprintable Story#

• 大小：以天計，小到足以放入 Sprint 實作
• 有些團隊稱之為 sprintable story 或 implementable story 以區別於更大的項目

Theme（主題）#

• 一組相關 Story 的集合，共享某個共同點（如同一功能領域）
• 像是用橡皮筋綁在一起的一疊便條卡上方的摘要卡

Task（任務）#

• 位於 Story 下方，通常以小時計
• 描述的是 how（怎麼做）而非 what（做什麼）
• 通常由一個人或一對人完成
• Task 不是 Story，撰寫 Story 時應避免包含任務層級的細節

Epic、Feature、Story、Theme 只是方便的標籤，並非普遍統一的。重要的是認知 Story 可存在於多個抽象層級，以支援多層級規劃與漸進精煉。

INVEST 準則#

Bill Wake 提出六個標準（以 INVEST 縮寫記憶），用來評估 User Story 的品質。

Independent（獨立）#

User Story 應盡可能獨立或僅鬆散耦合。高度相依的 Story 會讓估算、排序與規劃變得極為困難。目標不是消除所有相依性，而是以最小化相依的方式撰寫 Story。

Negotiable（可協商）#

Story 的細節應該是可協商的——它不是前期需求文件形式的書面合約，而是後續將透過對話協商細節的佔位符。

• Story 應描述 what（做什麼）和 why（為什麼），而非 how（怎麼做）
• 當 how 變得不可協商時，團隊創新的機會就會減少
• 特例：法規義務或商業限制可能要求特定實作方式，這是可以接受的

Valuable（有價值）#

Story 必須對客戶（Customer）、**使用者（User）**或兩者都有價值。

關於技術 Story：

• Product Owner 必須理解為什麼要為它買單，以及它最終將交付什麼價值
• 例如「遷移到新版 Oracle」——團隊解釋繼續在不支援版本上開發的風險後，Product Owner 可以做出知情的權衡

大多數像「自動化建置」這類技術 Story 不應列入 Product Backlog。它們應該是完成商業價值 Story 的任務。如果團隊有強健的 Definition of Done，這些工作已隱含在 Done 的定義中。

價值準則的核心：Product Backlog 中的所有 Story 都必須從 Product Owner 的角度來看是值得投資的。不是所有 Story 都能獨立，也不是所有 Story 都完全可協商，但它們全部必須有價值。

Estimatable（可估算）#

Story 應該可以被將要設計、開發和測試它的團隊估算。無法估算通常因為：

• Story 太大或太模糊——需要與 Product Owner 合作拆分
• 團隊缺乏知識——需要某種探索活動來獲取資訊

Sized Appropriately / Small（大小適當）#

Story 的大小應與預計工作時間匹配：

• Sprint 中的 Story 應為數天大小（幾週的 Sprint 中要有多個 Story）
• 一年後才會做的 Epic 級 Story 目前的大小是適當的——現在拆分反而浪費時間
• 下個 Sprint 就要做的 Epic 級 Story 則大小不適當，必須進一步拆分

Testable（可測試）#

Story 應以二元方式可測試——通過或不通過。可測試意味著有良好的驗收標準（即前述的 Conditions of Satisfaction）。

• 沒有可測試的標準，Sprint 結束時無法判定 Story 是否完成
• 例外：Epic 級 Story 通常不需要測試；某些非功能性需求（如 99.999% uptime）可能無法實際測試，但仍能驅動設計

非功能性需求（Nonfunctional Requirements）#

非功能性需求代表系統層級的約束。可以用 User Story 格式撰寫，也可以用其他更方便的格式。

例如：

• User Story 格式：「As a user I want an interface in English, a Romance language, and a complex language so that there is high statistical likelihood that it will work in all 70 required languages.」
• 簡潔格式：「System must support IE8, IE9, Firefox 6, Firefox 7, Safari 5, and Chrome 15.」

作為系統層級約束，非功能性需求影響 Product Backlog 中大部分或所有 Story 的設計與測試。

建議將盡可能多的非功能性需求納入 Definition of Done。例如將「Web Browser Support」納入 DoD，則每個 Sprint 新增的功能都必須在所有列出的瀏覽器上測試。延遲測試非功能性需求會延後對關鍵系統效能特性的快速回饋。

知識獲取型 Story（Knowledge-Acquisition Stories）#

有時需要建立專注於知識獲取的 PBI——原型（prototype）、概念驗證（proof of concept）、實驗（experiment）、spike 等。這些本質上都是購買資訊的探索活動。

經濟合理性判斷#

以架構評估為例：

1. 估算獲取成本：團隊估算原型開發的大小（例如一個 Sprint），換算成金額（例如 $10K）
2. 估算資訊價值：假設拋硬幣決定架構，猜錯的代價是多少？（例如 $500K）
3. 做決策：花 $10K 購買期望價值 $250K（一半機率猜對）的資訊？值得

反例：若猜錯代價只有 $15K，花 $10K 做原型反而不划算（期望價值只有 $7.5K），不如直接做最佳猜測，錯了再改——這就是所謂的快速失敗策略（fail-fast strategy）。

收集 Story 的技術#

User-Story-Writing Workshop#

目標是集體腦力激盪期望的商業價值，建立 User Story 佔位符。

• 參與者：Product Owner、ScrumMaster、開發團隊、內外部利害關係人
• 時長：數小時到數天，目標不是產出完整的需求集合
• 流程：
  1. 先進行使用者角色分析（user role analysis），確定可填入 Story 模板中 user role 的角色集合
  2. 可搭配人物誌（persona）——代表角色核心特徵的典型人物（例如「Lilly」代表 7-9 歲女性玩家）
  3. 由上而下：從 Epic 開始拆解出較小的 Story
  4. 由下而上：直接腦力激盪下一個 Release 的 Story
  5. 兩種方法可切換使用

Story Mapping（故事地圖）#

Story Mapping 由 Jeff Patton 推廣，從使用者中心的角度來產生 User Story：

1. 最上層是 Epic：代表對使用者有可衡量經濟價值的大型活動（如「Buy a Product」）
2. 分解為 Theme：沿時間軸排列使用者任務的工作流程，較早發生的在左邊（如「Search for Product」在「Manage Shopping Cart」左邊）
3. 每個 Theme 分解為 Story：垂直排列，按優先級（或期望度）由上往下排序
4. 不是所有同一 Theme 下的 Story 都必須在同一 Release 中

Story Mapping 結合了使用者中心設計與Story 拆解，提供了 Product Backlog 的二維視圖（相對於傳統的一維線性列表），讓人更容易理解個別 Story 與更大使用者價值單元之間的關係，也更容易發現遺漏的重要 Story。