Scrum 指南 · 工件与实践
Scrum 中的产品待办事项列表：是什么及如何管理
产品待办事项列表是一份涌现式的有序列表，列出改进产品所需的内容。在 Scrum 中，它是 Scrum 团队所承担工作的唯一来源，其承诺是 产品目标.
要点总结
- 产品待办事项列表是一份涌现式的有序列表，是 Scrum 团队工作的唯一来源。
- 产品负责人对其负责；开发人员估算条目规模。
- 其承诺是产品目标，为待办事项列表指明方向。
- 保持其简短、有序，并对顶部条目进行梳理，同时删除不再增加价值的条目。
产品待办事项列表是什么
产品待办事项列表是以下三者之一： Scrum 工件，以及 冲刺待办事项列表 和 增量。它包含 Scrum 团队目前认为可能为产品增加价值的一切：新功能、变更、修复、技术工作、调研和实验。
- 涌现式： 它永远不会完成。随着团队和相关方不断学习，条目会被添加、修改和删除。
- 有序： 条目有明确的顺序，让每个人都能看到接下来要做什么。2020 版《Scrum 指南》用的是“排序”而不是“确定优先级”，因为排序除了优先级之外，还可以反映价值、风险、依赖关系和学习需要。
- 唯一的工作来源： 只要 Scrum 团队将要处理某项工作，它就应在产品待办事项列表中可见。
- 每个产品一个： 开发同一产品的多个 Scrum 团队共享一个产品待办事项列表和一位产品负责人。
谁拥有产品待办事项列表
产品负责人 对有效的产品待办事项列表管理负责。根据 2020 版《Scrum 指南》，这包括：
- 制定并明确传达产品目标。
- 创建并清晰地传达产品待办事项列表条目。
- 对产品待办事项列表条目进行排序。
- 确保产品待办事项列表透明、可见且被理解。
产品负责人可以请他人完成部分工作，但仍需对此负责。将实际完成工作的开发人员负责估算条目规模，而 Scrum Master 帮助产品负责人找到有效的待办事项列表管理技巧。任何想要更改产品待办事项列表的人都需要说服产品负责人。
产品目标
产品目标描述了 Scrum 团队为之规划的产品未来状态。它位于产品待办事项列表中，产品待办事项列表的其余部分随之涌现，以定义如何实现它。团队应先实现或放弃一个产品目标，再着手下一个。
| 级别 | 承诺 | 示例 |
|---|---|---|
| 产品待办事项列表 | 产品目标 | 客户无需致电客服即可在线管理整个账户 |
| 冲刺待办事项列表 | 冲刺目标 | 客户可以下载 PDF 格式的历史发票 |
| 增量 | 完成的定义 | 代码已评审、已测试、符合无障碍要求并已部署到生产环境 |
产品待办事项列表条目包含哪些内容
《Scrum 指南》没有规定格式。属性因工作领域而异，但大多数团队会记录：
| 属性 | 目的 |
|---|---|
| 描述 | 需要什么以及为什么；通常写成 用户故事 |
| 排序 | 相对于其他条目的位置 |
| 规模 | 由开发人员做出的估算，例如以 故事点 |
| 验收标准 | 确认条目达到预期效果的条件 |
| 价值或理由 | 预期的成果或收益 |
| 备注和链接 | 设计、调研、依赖关系或相关的 史诗 |
靠近顶部的条目小而清晰、详细。靠下的条目可以更大、更模糊，因为过早添加的细节往往会被浪费。能够在一个冲刺内完成的条目被视为已就绪，可在以下活动中被选择： 冲刺计划会.
如何逐步管理产品待办事项列表
实例：为一个小型待办事项列表排序
一个在线预约服务的产品负责人设定的产品目标是“客户无需打电话即可预约和更改预约”。开发人员已估算了各条目的规模。产品负责人通过权衡价值与规模和风险对它们进行排序：
| 排序 | 条目 | 规模（点数） | 排在此位置的原因 |
|---|---|---|---|
| 1 | 在线预约 | 8 | 产品目标的核心；没有它，其他一切都无用 |
| 2 | 预约后发送确认邮件 | 3 | 价值高、规模小，减少爽约 |
| 3 | 更改或取消预约 | 5 | 直接减少电话量 |
| 4 | 探针：日历服务商集成 | 2 | 在条目 5 之前降低风险 |
| 5 | 将预约同步到员工日历 | 8 | 有价值，但取决于探针的结论 |
| 6 | 会员折扣码 | 13 | 当前产品目标不需要 |
如果团队的 速度 约为 15 点，条目 1 至 3（16 点）略多于一个冲刺的容量，因此团队可能计划条目 1 和 2 以及探针，然后在下一个冲刺处理条目 3。条目 6 可能会被删除，或搁置到之后的产品目标中。
产品待办事项列表与冲刺待办事项列表对比
| 产品待办事项列表 | 冲刺待办事项列表 | |
|---|---|---|
| 内容 | 所有可能改进产品的内容 | 冲刺目标、选定的条目和计划 |
| 批准（Accountable） | 产品负责人 | 开发人员 |
| 承诺 | 产品目标 | 冲刺目标 |
| 时间范围 | 产品的整个生命周期 | 一个冲刺 |
| 变化内容 | 每当产品负责人重新排序或添加条目时 | 每天，随着开发人员的了解不断加深 |
常见错误
- 只增不减的待办事项列表。 数百条陈旧的条目会掩盖真正重要的内容。删除或归档不再服务于产品目标的条目。
- 一个产品有多个待办事项列表。 各团队分别维护待办事项列表，导致无法在整个产品范围内排序。
- 所有事情都是“高优先级”。 排序是严格的先后顺序，而不是一组标签。
- 过早细化过多细节。 为数月后才处理的条目编写的详细规格通常会被重写。
- 产品负责人单打独斗。 梳理工作最好与开发人员和相关方协作完成。
- 没有产品目标。 没有它，待办事项列表就会沦为一份请求清单，而不是创造价值的计划。
本主题的免费模板
常见问题
Scrum 中的产品待办事项列表是什么？
它是一份涌现式的有序列表，列出改进产品所需的内容，是 Scrum 团队工作的唯一来源。其承诺是产品目标。
谁拥有产品待办事项列表？
产品负责人对其负责。其他人可以贡献条目，也可能被要求完成部分工作，但由产品负责人决定排序。
谁可以向产品待办事项列表添加条目？
任何人都可以提出条目建议，在许多团队中开发人员会直接添加条目。产品负责人仍对内容和排序负责。
按优先级划分的产品待办事项列表与排序的产品待办事项列表有什么区别？
确定优先级通常意味着将条目标记为高、中或低。排序则意味着将每个条目放入单一序列，可以反映价值、风险、依赖关系和学习需要。
产品目标与产品待办事项列表有何关系？
它是产品待办事项列表的承诺：Scrum 团队为之规划的产品未来状态。团队一次只致力于一个产品目标。
产品待办事项列表应该有多大？
没有硬性规定。如果待办事项列表长到无法通读和排序，就会难以管理，因此许多团队只保留几个冲刺的详细条目，其余作为较大的粗粒度条目。
产品待办事项列表条目必须是用户故事吗？
不必。《Scrum 指南》没有规定格式。用户故事很流行，但条目也可以是缺陷、技术任务、实验或简单的描述。
谁来估算产品待办事项列表条目？
将实际完成工作的开发人员负责估算规模。产品负责人可以帮助他们理解条目和权衡取舍。
产品待办事项列表条目何时算就绪？
《Scrum 指南》指出，能够在一个冲刺内完成的条目被视为已就绪，可在冲刺计划会中被选择。一些团队会额外制定可选的就绪的定义。
多个团队可以共享一个产品待办事项列表吗？
可以。在 Scrum 中，一个产品只有一个产品待办事项列表和一位产品负责人，即使有多个团队在开发它。
产品待办事项列表和项目计划是一回事吗？
不是。它是一份针对产品不断演进的列表，而不是固定的计划，尽管它可以与预测和以下内容结合使用： 发布计划.
可以使用哪些工具管理产品待办事项列表？
从电子表格或便利贴到以下工具均可，例如 Jira 或 Trello。参见 Scrum 软件工具.