Mike Cohn 解析：产品待办列表梳理

产品待办列表梳理——过去称为 “待办列表梳理”，旨在保持产品待办列表的整洁有序——是在一个迭代接近尾声时召开的会议，目的是确保待办列表为下一个迭代做好准备。

我倾向于在当前迭代结束前三天召开产品待办列表梳理会议。这能让产品负责人有足够时间处理会议中发现的问题。当然，有些团队发现每周召开短会比每迭代一次开会更符合他们的节奏，这也完全可行。

谁应该参加产品待办列表梳理会？

产品待办列表梳理并非 Scrum 中的正式事件，但 2020 版《Scrum 指南》将其列为每个迭代中应进行的活动。因此，关于参会人员尚未形成共识。

虽然我一直坚信整个团队应参与其中，但这在实际会议中并不现实，原因如下：

1. 产品待办列表梳理通常在迭代结束前两到三天进行，此时团队中往往有人正忙于迭代收尾工作。若强制其参会，可能会影响他们正在处理的产品待办事项的交付。

2.一条经验法则是：每个迭代中约 5% 到 10% 的精力应投入待办列表梳理。尽管整个团队参与固然理想，但并非所有团队成员都能全程参加。

产品待办列表梳理会上会发生什么？

在产品待办列表梳理会议期间，团队成员和产品负责人会讨论产品待办列表中优先级最高的事项。这个环节让团队成员有机会提出在迭代计划阶段通常会出现的问题，例如：

· 如果用户在此处输入无效数据，该如何处理？

· 所有用户都允许访问系统的这部分功能吗？

· 如果…… 会发生什么？

基于这些问题的答案，团队可能会拆分用户故事，使其细化到足以纳入单个迭代。使用故事点进行敏捷估算的团队还会对优先级上升的新故事或拆分后的故事添加估算。

为什么要梳理产品待办列表？

通过提前对即将开发的故事提出问题，产品负责人有机会思考并回答那些在迭代计划时可能无法立即解决的问题。如果这些问题在迭代计划时首次被提出，且大量问题无法解答，可能需要将高优先级的产品待办事项搁置，不在当前迭代中处理。

这些问题无需在梳理会议中完全解决，产品负责人只需做出足够回应，让团队有信心在即将到来的计划会议中充分讨论该故事即可。

从这个意义上讲，待办列表梳理更像是一个 “检查点”，而非彻底解决问题的环节。

如何最大化其价值？

最大化待办列表梳理会价值的方法，可能和所有高效会议的关键要素一致：

· 会议时长尽可能简短；

· 参会者提前做好准备；

· 鼓励全员参与；

请记住，关于产品待办列表的讨论不应局限于特定时间或单次会议，任何人都可以随时参与。虽然我之前提到梳理会常在迭代结束前两到三天召开，但最终节奏应由团队自行决定。

梳理待办列表时，请记住：不必在迭代开始时就完全理解所有产品待办事项（通常以用户故事形式存在），只需确保团队对其有足够的理解，从而有合理的可能性在迭代中完成即可。

待办列表梳理会能有趣吗？

我很难将任何会议定义为 “真正有趣”，但我认为，与合适的团队成员合作时，会议可以成为紧张工作中的 “受欢迎的休息时刻”。

优秀的团队会形成一种节奏：交替进行高强度的个人或结对脑力工作，并偶尔插入会议。会议可以带有社交基调，比如和队友开开玩笑，或在重新投入紧张工作前放松大脑。

我听说过人们用各种方式让 Scrum 事件变得有趣。大多数想法围绕 “每天站会迟到的惩罚”（例如往罐子里投钱、在队友面前唱歌或讲笑话），但这并不意味着这些创意不能启发我们用不那么尴尬的方式保持梳理会的轻松氛围。

比如花几分钟聊聊近况、家庭或其他话题，让会议显得不那么令人望而生畏。

总之，产品待办列表梳理不必每个迭代都进行，但你应该预留时间，确保产品待办列表顶部始终是适合单个迭代的小颗粒度条目，从而暂缓对后期才需开发的条目投入精力。

最后更新：2023 年 9 月 26 日

-------------------------------------------

Mike Cohn

关于作者

迈克・科恩专注于帮助企业采用和优化敏捷流程与技术，以打造高绩效团队。他是《用户故事与敏捷软件开发》《敏捷估算与规划》《敏捷转型》等著作的作者，并开设了《更好的用户故事》视频课程。

译者：Wendy Zheng

审校：Daisy Guo, CSP-SM

原文链接：https://www.mountaingoatsoftware.com/blog/product-backlog-refinement