产品待办列表 Product Backlog | Product Backlog Item PBI

定义：

这其实就是一个需求列表，由PO根据业务价值、风险、依赖关系和所需的交付日期等考虑因素进行管理和连续排序。它可以包含产品所需：业务需求、特性、缺陷、变更和非功能性需求。理想情况下，产品待办事项列表中的每一项（称为：Product Backlog Item，缩写：PBI）都应该以用户故事的格式表示。这个列表是动态的，PO会不断地将其按优先级排序，确保最有价值的PBI（所谓：带来最高的ROI）被详细地列入并最顶部（优先做）。

1. 不完整的：因为需求永不停止改变（增加、删除）
2. 动态的：会根据商业环境发生变动
3. 排序的：PO负责保证优先级反应高价值
4. 可中断：因低价值，剩下可以不做
5. 渐近明细：（按重要性）排序越高、优先级越高、详细程度越高
6. 使用用户故事来表示
7. 颗粒度不一样
8. 包括：特征、功能、需求、改进、缺陷修复、非功能特性
9. 包括：测试、用例的描述，即验收标准。将在完成时证明完整性

动态的

PO不断更新产品待办事项列表，以响应项目环境中的一个或多个事件：

1. 在Sprint评审会议的产品评审过程中出现了一个新的需求。
2. 实施了监管限制。
3. 市场上的经济条件（商品的股价或汇率）发生了变化可能会影响产品的商业价值。因此，功能既可以被添加，也可以被删除。
4. 一个新的细分客户被发现（或者已经表达了使用产品的愿望）。
5. 发现与其他内部产品（在同一组织中)）或外部接口（在组织边界外）的依赖关系。
6. 团队确定需要减轻的风险。
7. 该产品应抓住竞争优势，因为竞争对手提供类似的产品。
8. 有影响体系结构和设计的技术考虑因素。

排序的

版本线划分

发布计划，到，迭代计划

符合DEEP原则

DEEP原则

• ★★★DEEP原则★★★
  • 详略适当 Detailed Appropriate
  • 不断涌现 Emergent
  • 可估算的 Estimated
  • 排优先级 Prioritized

详略适当 Detailed Appropriate

• 产品待定列表事项（PBI）应该有足够的细节，可以用来向项目团队传递必要的信息。请注意，在发布计划和Sprint计划期间，PO和开发团队之间的对话会不断出现，目的是讨论PBI和用户故事的细节。具有高业务价值的PBI应该有更多的细节，因为它们更有可能被早期实现（例如，后续迭代）。遵循渐进明细原则，将较低优先级的PBI放在较低的细节级别上。

  不断涌现 Emergent

• “涌现”一词表示产品待办事项列表是一个动态列表。在项目的生命周期中，它预计会增加、改变并重新排列优先级。由开发团队完成的项目（即满足其DoD）将从待办事项列表中删除。请注意，团队中的任何人都有权向产品待办事项列表中添加PBI。然而，PO对待办事项列表中PBI的价值和优先级有最终的发言权。

  可估算的 Estimated

• PBI应该有足够的细节使其可估算。位于待办事项列表顶部的项目具有最高的优先级，并且被期望具有更细小粒度用于估算。敏捷估算并不产生精确的值，而是根据大小和复杂性的相对排序，通常以理想时间或故事点为单位来表示。敏捷团队通常使用亲和估算这样的技术，从产品待办事项列表中快速生成一个非常大的项目列表的粗略估计。一旦进行了评估，PO就能够生成一个发布计划，在这个计划中干系人可以看到业务价值是如何随着时间的推移而实现的。

  排优先级 Prioritized

• PO的角色是确保产品待办事项列表的优先级，在待办事项列表的顶部具有最高价值的PBI，在待办事项列表的底部具有最低价值的PBI。按优先级排序的产品待办事项列表。

包含内容：特性、变更、缺陷、技术改进、知识获取

• 特性 Feature
  • 作为客户服务代表，我希望为客户支持问题创建一个记录卡，这样可以记录和管理客户的支持请求
• 变更 Change
  • 作为客户服务代表，我希望搜索结果在默认情况下按照姓氏排序，不要按记录卡号排序，这样可以更容易查找支持记录卡
• 缺陷 Defect
  • 修复缺陷跟踪系统中的缺陷#256，这样可以使客户在搜索项中输入特殊字符时不会出现异常
• 技术改进 Technical improvement
  • 迁移到最新版Oracle数据库管理系统
• 获取知识 Knowledge acquisition
  • 为两种架构同时创建原型或概念验证，执行三次测试，这样可以确定哪种方法更适合产品

实例：