如何使用 DEEP 原則管理產品待辦事項？

產品待辦事項是產品中已知和需要的所有內容的  有序列表。它是對產品進行任何更改的單一需求來源。

產品所有者負責產品待辦事項，包括其內容、可用性和訂單。

產品積壓清單永遠不會完成。業務需求、市場條件或技術的變化可能會導致產品待辦事項列表的變化。它隨著產品的發展和項目環境的變化而發展。項目的需求永遠不會停止變化，因此產品待辦事項列表就像一個不斷發展的 Scrum 工件。

產品積壓中的高優先級項目是細粒度的。因為這些項目有更多的信息和細節，因此他們有更準確的估計。

優先級較低的項目是較大的項目，細節不太清楚。隨著團隊獲得有關低優先級項目的更多詳細信息，它們將進一步分解為更小的項目。開發團隊負責不時評估產品待辦事項中的這些項目。

深入產品待辦事項管理

產品待辦事項列出了產品發布所需的所有特性、功能、要求、增強和修復。產品待辦列表項目具有描述（適當詳細）、故事點（E估計）和訂單（優先 級）的屬性。它們必須在積壓工作中不斷添加、刪除和更新（E合併），並及時、適當地反映對團隊積壓工作的理解。

Roman Pichler 是敏捷產品管理與 Scrum 的作者提到：

“創造客戶喜愛的產品。我們使用四個字母的縮寫 DEEP 來描述一個好的產品 Backlog 的特徵。” 是 Scrum 中對 backlog 產品質量的描述性縮寫，代表：  Detailed proper 、  E mergent、  E stimated 和 P rioritized。

適當詳細

靠近產品待辦列表頂部的故事將在下一個 sprint中發揮作用，因此這些項目需要定義得足夠好，以便團隊更高效地處理它們。通常，待辦事項頂部附近的故事更小且粒度更細，但在產品待辦事項列表中的下方逐漸變大且不具體，如下圖所示：

估計的

Product Backlog 中的項目是估計的。待辦事項頂部的項目具有更準確的估計。較低優先級的項目在高級別進行估計，並且可以在團隊獲得更多信息時重新估計。

緊急

Product Backlog 不是一成不變的，它在不斷變化。隨著項目的進行，獲得越來越多的信息和知識，產品Backlog中的用戶故事也被添加、刪除或重新排列。

優先

在Product Backlog當中，越有價值的條目優先級越高，上面的條目的值越低，在Product Backlog中的條目的優先級越低，在Product Backlog之後。團隊總是完成高優先級的條目，以確保正在開發的產品或系統的價值最大化。

概括

DEEP 是一個有用的概念，可應用於 Product Backlog 細化 過程，該過程涉及向 Product Backlog 中的項目添加細節、估計和訂單並保持其形狀的行為。

在產品待辦列表細化期間，項目會被審查和修訂。Scrum 團隊決定如何以及何時完成細化。細化通常消耗不超過開發團隊10%的能力。但是，產品積壓項目可以由產品負責人隨時更新，也可以由產品負責人自行決定。