Scrum 指南 · 工件与实践
Scrum 中的待办事项列表梳理：如何做好
待办事项列表梳理是一项持续进行的活动，旨在分解产品待办事项列表条目并为其补充细节，例如描述、排序和规模。在 Scrum 中，它不是正式事件：它使 产品待办事项列表 足够清晰，使团队能够有信心地规划冲刺。
要点总结
- 待办事项列表梳理是一项持续进行的活动，而不是正式的 Scrum 事件。
- 它分解条目并补充细节，例如描述、排序和规模。
- 产品负责人和开发人员共同梳理；由开发人员估算工作规模。
- 保持约一到两个冲刺的条目处于就绪状态，并进行纵向拆分。
梳理是什么，不是什么
2020 版《Scrum 指南》将产品待办事项列表梳理描述为将条目分解并进一步定义为更小、更精确的条目的行为。它是一项持续进行的活动，因此不属于五个 Scrum 事件。许多团队仍会举行定期的梳理会议，因为这能让工作更可预测。
| 梳理是 | 梳理不是 |
|---|---|
| 澄清条目的含义及其重要性 | 为下一个冲刺承诺工作 |
| 将大型条目拆分为较小的条目 | 将任务分配给个人 |
| 估算条目规模，以便排序和预测 | 每个条目的详细技术设计 |
| 添加验收标准 | 状态会议 |
| 持续进行且协作完成 | 由产品负责人独自完成的事情 |
参与者
- 产品负责人： 提供背景信息，解释条目的价值并接受权衡取舍。对待办事项列表负责。
- 开发人员： 提出问题，建议拆分方式和更简单的方案，并估算条目规模。《Scrum 指南》规定由他们负责规模估算。
- Scrum Master： 在需要时提供帮助，例如指导团队掌握拆分技巧，或让会议保持聚焦。
- 相关方和专家： 当某个条目需要其专业知识时受邀参加，例如客户、设计师或合规专家。
应投入多少时间
2020 版《Scrum 指南》没有为梳理设定时间限制。早期版本建议梳理通常不超过开发人员产能的 10%，许多团队至今仍将其作为粗略参考。在为期两周的冲刺中，这通常意味着一到两次约一小时的会议，外加非正式的交流。
如何开展梳理会议
- 准备。 产品负责人挑选出待办事项列表顶部需要关注的条目，并提前分享。
- 解释原因。 对于每个条目，产品负责人描述问题、用户以及期望的成果。
- 提出并解答问题。 开发人员探讨边界情况、依赖关系和风险。记录未决问题以及由谁负责解答。
- 商定验收标准。 写下能够证明该条目有效的条件。
- 必要时进行拆分。 如果一个条目无法在一个冲刺内完成，就将其拆分为更薄的切片，且每个切片仍能交付价值。
- 估算规模。 开发人员进行估算，例如使用 故事点 和计划扑克。
- 重新排序。 产品负责人根据所获得的认识调整排序。
- 收尾。 确认哪些条目已为冲刺计划会做好准备，以及需要哪些后续跟进。
拆分大型条目的方法
| 技巧 | 示例 |
|---|---|
| 按工作流程步骤 | “结账”拆分为购物车确认、配送信息和支付 |
| 按业务规则 | 先支持标准配送，之后再支持快递配送 |
| 按数据或输入类型 | 先支持银行卡支付，再支持数字钱包 |
| 按用户或角色 | 先面向客户，再面向管理员 |
| 先简单实现，再逐步改进 | 先做基本搜索，再做筛选，最后做保存的搜索 |
| 先做技术探针 | 在估算不确定条目之前进行的有时间盒的调查 |
进行纵向拆分，使每个切片都能独立使用，而不是按数据库、界面和测试等层次横向拆分。参见 史诗、故事与任务.
计算示例
一个团队在梳理“客户可以跟踪其订单”这一条目，开发人员认为它大约有 20 点，对于一个冲刺来说太大了，因为他们在处理其他工作的同时通常只能完成约 25 点。经过讨论，他们将其拆分为：
| 新条目 | 验收标准（摘要） | 规模 |
|---|---|---|
| 在账户页面显示订单状态 | 状态显示已下单、已打包、已发货或已送达 | 5 |
| 订单发货时发送电子邮件 | 10 分钟内发送电子邮件，附跟踪链接 | 3 |
| 在账户页面显示快递跟踪信息 | 通过快递公司 API 实时跟踪 | 8 |
| 技术探针：快递公司 API 限制 | 解答：我们能否每 15 分钟轮询一次？ | 2 |
总计 18 点，且每个条目都可独立使用。产品负责人将状态页面和电子邮件排在最前面，因为它们交付了大部分价值；其次是技术探针，这样当跟踪条目排到顶部时风险更低。
技巧与常见错误
- 持续进行梳理，而不只是在冲刺计划会前一天匆忙进行。
- 保持会议简短，并聚焦于待办事项列表的顶部。
- 让整个团队参加，或至少让可能承担该工作的开发人员参加；由一个人估算规模会失去共同理解。
- 不要过度细化：为冲刺期间的对话留出空间。
- 如果有帮助，可以使用一份轻量级检查清单（有时称为就绪的定义），但不要把它变成阻碍有用工作的关卡。
- 将未决问题公开跟踪，确保在冲刺计划会之前得到解答。
本主题的免费模板
常见问题
Scrum 中的待办事项列表梳理是什么？
它是一项持续进行的活动，旨在分解产品待办事项列表条目并为其补充细节（例如描述、排序和规模），使其为冲刺计划会做好准备。
待办事项列表梳理是 Scrum 事件吗？
不是。2020 版《Scrum 指南》将其描述为一项持续进行的活动，而不是五个事件之一。团队仍可安排定期的梳理会议。
待办事项列表梳理与待办事项列表整理（grooming）是一回事吗？
是的。整理（grooming）是较早的术语；《Scrum 指南》已用梳理（refinement）取而代之，梳理现在是标准名称。
谁参加待办事项列表梳理？
产品负责人和开发人员，Scrum Master 在需要时提供帮助。当某个条目需要相关方或专家的意见时，他们也会参加。
待办事项列表梳理应花多长时间？
2020 版《Scrum 指南》没有规定上限。早期版本建议不超过开发人员产能的约 10%，这至今仍是常用的参考标准。
应该多久梳理一次待办事项列表？
持续进行。许多团队每个冲刺举行一到两次简短的会议，较小的问题则随时处理。
待办事项列表梳理期间由谁进行估算？
将实际完成工作的开发人员。产品负责人解释条目和权衡取舍，但不设定估算值。
待办事项列表梳理和冲刺计划会有什么区别？
梳理是随时间逐步准备条目。冲刺计划会是一个有时间盒的事件，团队在其中设定冲刺目标、选择条目并规划工作。
待办事项列表梳理中的“就绪”是什么意思？
《Scrum 指南》指出，能够在一个冲刺内完成的条目被视为已就绪，可在冲刺计划会中被选择。一些团队会额外制定可选的就绪的定义。
应该提前多久梳理待办事项列表？
通常足够接下来一到两个冲刺即可。梳理得过于超前可能造成浪费，因为优先级和理解都会变化。
待办事项列表梳理可以在冲刺期间进行吗？
可以。它贯穿整个冲刺，与当前冲刺待办事项列表上的工作同步进行。
如果待办事项列表梳理会议总是超时怎么办？
提前准备条目，聚焦于待办事项列表顶部，为每个条目设定时间盒，并将深入的技术问题移至规模较小的后续讨论或技术探针中。