Product Backlog 是 Scrum 開發專案中最核心的產出物（artifact）之一。本章探討 Product Backlog 的組成、良好特徵、梳理活動，以及如何透過它管理快速且靈活的交付流程。
概觀#
Product Backlog 是一份按優先順序排列的產品功能需求清單。它提供了一個集中且共享的理解——要建造什麼，以及建造的順序。只要產品還在被開發、增強或維護，Product Backlog 就會一直存在。
Figure 6.1: The product backlog is at the heart of the Scrum framework.
Product Backlog Items（PBI）#
Product Backlog 由多個 Backlog Item（PBI） 組成，主要可分為以下幾類：
Figure 6.2: Product backlog items
| 類型 | 說明 |
|---|---|
| Features（功能） | 對使用者或客戶有實質價值的功能項目，通常以 User Story 形式撰寫 |
| Defects（缺陷） | 需要修復的錯誤 |
| Technical Work（技術工作） | 例如升級資料庫版本等技術改善 |
| Knowledge Acquisition（知識探索） | 例如建立原型或概念驗證（proof of concept），用以驗證技術方案 |
Scrum 並未規定 PBI 的格式，但 User Story 是最常見的寫法。PBI 的類型不限於功能需求，任何 Product Owner 認為有價值的工作都可以放入 Product Backlog。
良好 Product Backlog 的特徵（DEEP）#
Roman Pichler 與 Mike Cohn 提出了 DEEP 縮寫，用來描述良好 Product Backlog 的四項特徵：
Detailed Appropriately（適度詳細）#
並非所有 PBI 都需要在同一時間達到相同的細節程度：
- 近期要做的項目：位於 Backlog 頂部，體積小、細節充分，可直接放入 Sprint
- 未來才做的項目：位於 Backlog 底部，體積大、細節較少
Figure 6.3: Product backlog items are different sizes.
拆解時機要掌握「恰到好處」（just enough）與「恰在其時」（just in time）的平衡。過早細化會浪費時間在可能永遠不實作的項目上；過晚細化則會阻礙 Sprint 的流暢進行。
Emergent（持續演化）#
Product Backlog 永遠不會「完成」或「凍結」。它會根據持續到來的經濟性資訊不斷更新——客戶改變想法、競爭對手做出意外舉動、或出現未預見的技術問題。Product Owner 必須因應新資訊，持續重新平衡和調整優先順序。
Estimated（已估算）#
每個 PBI 都有對應的 大小估算（size estimate），反映開發該項目所需的工作量。
Figure 6.4: Product backlog items are estimated.
- 頂部項目較小、較精確，多以 Story Points 或 Ideal Days 表示
- 底部的大型項目（如 Epic）可能使用 T-shirt Size（L、XL、XXL）或尚未估算
- 隨著項目被拆解為較小的故事，會再以數字進行更精確的估算
Prioritized（已排序）#
Product Backlog 是排序過的清單，但不需要每個項目都精確排序：
Figure 6.5: Product backlog items are prioritized.
- 近期的項目（目標 Release 1）：應仔細排序
- 中期的項目（Release 2、3）：可依 Product Roadmap 做粗略歸類
- 遠期的項目：花時間精細排序是浪費，因為未來充滿變數
梳理（Grooming）#
要獲得一個好的 DEEP Product Backlog，必須主動地進行 梳理（Grooming） 活動。
什麼是 Grooming？#
Grooming 包含三項主要活動：
- 建立與細化 PBI：新增項目或為既有項目增添細節
- 估算 PBI：為項目評估大小
- 排序 PBI：調整優先順序
Figure 6.6: Grooming reshapes the product backlog.
具體操作包括：插入新項目、重新排序、將大項目拆分為多個小項目、刪除不再需要的項目等。
誰來做 Grooming？#
Grooming 是由 Product Owner 主導，但需要多方協作的持續性活動：
Figure 6.7: Grooming is a collaborative effort.
| 角色 | 職責 |
|---|---|
| Product Owner | 最終決策者，主導整體方向 |
| 內部利害關係人 | 業務負責人、經理、專案管理 |
| 外部利害關係人 | 客戶、使用者、合作夥伴、監管機構 |
| ScrumMaster | 協助促進梳理活動 |
| 開發團隊 | 應分配每個 Sprint 約 10% 的時間協助梳理 |
協作式的 Grooming 能促進重要對話、整合多元觀點，讓所有人對 Product Backlog 有更清晰的共識，減少溝通浪費，並有助於縮短業務端與技術端之間的隔閡。
何時進行 Grooming？#
Scrum 框架只規定 Grooming「需要發生」，但不規定何時發生。實務上有多種時機：
Figure 6.8: Outside-of-primary-flow grooming with sequential projects
Figure 6.9: When grooming happens
| 時機 | 說明 |
|---|---|
| Release Planning 期間 | 進行初始的 Grooming |
| Sprint 期間的工作坊 | 每週一次或每個 Sprint 一次的專門會議 |
| Daily Scrum 之後 | 利用少量時間做增量式梳理，不需要所有成員都參加 |
| Sprint Review 期間 | 自然地產生新 PBI、重新排序或刪除不需要的項目 |
傳統瀑布式開發中，需求變更是「異常的、計畫外的」活動，透過獨立的變更控制流程處理。Scrum 則相反——Grooming 是開發流程中本質的、內建的一部分。
Definition of Ready（就緒定義）#
Grooming 的目標之一是確保 Backlog 頂部的項目已就緒（ready），可以被移入 Sprint。部分 Scrum 團隊會正式建立一份 Definition of Ready。
Figure 6.10: Definition of ready
Definition of Ready 是一份檢核清單，典型項目包括：
- 商業價值已清楚表達
- 開發團隊充分理解細節，能做出是否可完成的判斷
- 已識別相依性，且無外部相依性會阻礙完成
- 團隊有足夠人力來完成
- PBI 已估算且小到能在一個 Sprint 內完成
- 驗收標準清晰且可測試
- 效能標準（若有）已定義且可測試
- 團隊了解如何在 Sprint Review 展示該 PBI
強健的 Definition of Ready 能大幅提升團隊成功達成 Sprint Goal 的機會。它與 Definition of Done 形成 PBI 在 Sprint 週期中的兩個關鍵狀態。
stateDiagram-v2
[*] --> 待梳理: 新增 PBI
待梳理 --> 就緒: 通過 Definition of Ready
就緒 --> 進行中: Sprint Planning 選入
進行中 --> 完成: 通過 Definition of Done
完成 --> [*]: 納入產品增量
note right of 就緒
Ready 門檻：
明確、可估算、可測試
end note
note right of 完成
Done 門檻：
設計、編碼、整合、測試
end note流程管理（Flow Management）#
Product Backlog 是 Scrum 團隊在不確定性中達成快速、靈活價值交付的關鍵工具。
Release Flow Management#
Product Backlog 的梳理須支援持續的 Release Planning。可將 Backlog 用兩條線分為三個區域：
Figure 6.11: Release-level view of the product backlog
- Must Have（必要功能）：沒有這些就不是一個可行的客戶版本
- Nice to Have（期望功能）：目標包含在下個 Release，但資源不足時可捨棄
- Won’t Have（排除功能）：明確宣告不包含在當前 Release
Sprint Flow Management#
Product Backlog 可視為一條需求流水線（pipeline of requirements），需求從一端流入、經梳理後從另一端流出給團隊。
Figure 6.12: The product backlog as a pipeline of requirements
流程管理的重點在於平衡：
- 流入太慢：流水線枯竭，團隊無法規劃和執行下一個 Sprint
- 流入太快：產生大量已細化但可能需要重做或丟棄的需求庫存
實務上的經驗法則：保持約 2 到 3 個 Sprint 份量的就緒 PBI。例如團隊每個 Sprint 通常完成 5 個 PBI，就維持 10 到 15 個已就緒的 PBI。這既確保流水線不會枯竭，也提供了因應容量或限制條件而調整選取順序的彈性。
應該有幾個 Product Backlog？#
基本原則：一個產品，一個 Product Backlog。但在實務中有些情境需要特別考慮。
什麼是「產品」？#
Figure 6.13: The product backlog is associated with the product.
「產品」的定義並不總是明確。以 Microsoft Office 為例：Word 是獨立產品，還是 Office 套件的一部分？實務上可用簡單規則判斷：產品是客戶願意付費購買、而我們也願意包裝銷售的東西。
對於 Component Team（元件團隊）的情況需格外注意——目標應盡量減少元件團隊的數量，讓 Product Backlog 對齊最終交付給客戶的產品。
大型產品：階層式 Backlog#
對於大型產品（如手機開發有數十或上百個團隊），將所有 PBI 放入單一 Backlog 既不實際也不必要。解決方案是建立階層式 Backlog：
Figure 6.14: Hierarchical product backlogs
- 頂層：Product Backlog，描述大規模功能（Epic 級別），由一位 Chief Product Owner 負責
- 中層：各功能區域（Feature Area）各有自己的 Backlog
- 底層：團隊層級的 Backlog，包含可放入 Sprint 的 User Story
多團隊共用一個 Product Backlog#
當多個團隊共用一個 Product Backlog 時，若團隊可互換（任何團隊可做任何 PBI），則能真正實現全產品層級的優先順序最佳化。
若團隊不可互換，則需要團隊專屬的 Backlog 視圖（team-specific views），而非建立獨立的 Backlog：
Figure 6.15: Team-specific view of the product backlog
不可互換的團隊可能會讓某些團隊只能處理產品層級中優先順序較低的項目。這也是為什麼許多組織追求高度的共享程式碼所有權和更可互換的團隊。
一個團隊負責多個產品#
Figure 6.16: Scenarios for multiple product backlogs
當一個團隊必須負責多個產品時，有幾種處理方式：
- 最佳做法：每個 Sprint 只從一個 Product Backlog 取工作
- 合併 Backlog：若組織限制迫使團隊同時處理多個產品，可考慮將多個 Backlog 合併，各 Product Owner 共同排出跨產品的統一優先順序
- 維持獨立 Backlog：每個 Sprint 由某人（通常是團隊的 Product Owner）從各 Backlog 組合出一份排序過的 PBI 清單給團隊
小結#
Product Backlog 是在不確定環境中實現快速、靈活價值交付的核心工具。重點包括：
- PBI 的四種類型：Features、Defects、Technical Work、Knowledge Acquisition
- 良好 Backlog 的 DEEP 特徵：Detailed Appropriately、Emergent、Estimated、Prioritized
- Grooming 是持續性的協作活動，包含建立/細化、估算、排序三大面向
- Definition of Ready 確保進入 Sprint 的項目品質
- 透過 Release Flow 和 Sprint Flow 管理，維持需求的穩定流動
- 原則上一個產品一個 Backlog，但可依規模和組織結構靈活調整