产品待办列表是产品中已知需要的所有内容的有序列表。它是对产品进行任何更改的唯一要求来源。” 该产品负责人负责产品Backlog，包括它的内容，可用性和排序。
产品待办事项永远不会最终确定。业务需求、市场条件或技术的变化可能会导致产品待办列表发生变化。它随着产品和项目环境的发展而不断发展。项目的需求永远不会停止变化，因此产品待办事项列表就像一个活的Scrum 工件。
Product Backlog 中的高优先级项目是细粒度的，因为这些项目的信息和细节更多，所以有更多的细节和准确的估计。较低优先级的项目是具有高级别估计的大项目。随着团队获得有关较低优先级项目的更多详细信息，这些项目将进一步拆分为小项目。开发团队负责对产品待办列表中的项目进行估算。
DEEP 产品待办列表管理
产品待办列表列出了需要为产品发布开发的所有特性、功能、要求、增强和修复。积压的产品项目具有描述的属性（d etailed适当），故事点（ë stimated），顺序（P rioritized），并且它们是连续地添加，移除和更新（Ë在积压子公司Mergent），以反映到的理解以及时和恰到好处的方式处理团队的积压工作。
Roman Pichler 是提到 Scrum的敏捷产品管理的作者
“创造客户喜爱的产品。我们使用四字母缩写 DEEP 来描述一个好的产品 Backlog 的特征。”因此，团队‘深’是一种用于在产品积压的质量的描述缩写的Scrum经得起：Detailed appropriately, estimated, emergent, and prioritized
Read more at: Make Your Product Backlog DEEP Copyright © Pichler Consulting
深入产品待办事项
产品积压项目通常说明了一个常见的挑战：产品积压往往太长、太详细，因此难以使用。解决方案的一部分是确保您的产品积压用DEEP原则：应该适当地详细说明、估计、紧急情况和优先顺序。尤其是第一和第三个属性经常被忽视。
详细到位 (Detailed appropriately)
靠近产品待办列表顶部的故事将在下一个冲刺中发挥作用，因此需要对这些项目进行充分定义，以便团队能够更高效地处理它们。通常，待办事项列表顶部附近的故事较小且粒度更细，但在产品待办事项列表的更下方逐渐变大且不那么具体，如下图所示：
详细的产品积压
已估计的 (Estimated)
产品待办列表中的项目是估计的。待办列表顶部的项目有更准确的估计。较低优先级的项目在较高级别进行估计，并且可以在团队获得更多信息时重新估计。
用户故事故事点
紧急 (Emergent)
Product Backlog 不是一成不变的，它是在不断变化的。随着项目的进展，获得的信息和知识越来越多，产品Backlog中的用户故事也被添加、删除或重新排列。
敏捷优先产品待办列表
优先 (Prioritiezed)
在Product Backlog当中，优先级越高的条目越有价值，上面，Product Backlog中条目的值越低，优先级越低，在Product Backlog之后。团队总是完成高优先级条目，以确保正在开发的产品或系统的价值最大化。
优先的产品待办事项
DEEP 是一个有用的概念，可用于产品待办列表细化过程，该过程涉及向产品待办列表中的项目添加细节、估计和顺序并保持其形状的行为。
在产品待办列表细化期间，项目被审查和修订。Scrum 团队决定改进的方式和时间。细化通常不超过开发团队容量的 10%。但是，产品 Backlog 项目可以由产品负责人随时更新或由产品负责人自行决定更新。
References
- Write SMART Goals & INVEST for User Stories
- Theme vs Epic vs User Story vs Task
- What is DEEP in Product Backlog?
- How to Write Product Vision for Scrum Project?
- How to Use Scrum Board for Agile Development?
- Who Create Product Backlog Items or User Stories in Scrum?
- What is Agile Estimation?
- What is Story Point in Agile? How to Estimate a User Story?
- User Story Splitting - Vertical Slice vs Horizontal Slice
