如何使用 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%的能力。但是，产品积压项目可以由产品负责人随时更新，也可以由产品负责人自行决定。