Scrum: 管理产品待办事项 (Project Backlog) 的原则

产品待办列表是产品中已知需要的所有内容的有序列表。它是对产品进行任何更改的唯一要求来源。” 该产品负责人负责产品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