被精炼到「过劳死」的待办列表（以及一个团队如何把它救回来）
有一个分布式软件团队，我姑且称之为「阿特拉斯小队」，他们在2020年下半年完全居家办公。到了2021年1月，他们遇到了一个说不清的问题。他们的产品待办列表膨胀到了四百多条，每一条都精心撰写、估算并打了标签。然而冲刺规划总是拖得很长，冲刺进行到一半时同样的问题反复出现，团队也很少完成自己的预测。他们一直在不停地梳理，结果却越梳越糟。
《Scrum 指南》将产品待办列表梳理描述为：持续地把条目拆解并进一步细化为更小、更精确的部分，并补充描述、顺序和规模等细节。它不是一个单独的强制性事件，也不是一场文档比赛。阿特拉斯却在不知不觉中把它变成了比赛。
梳理是怎么走偏的
由于远程办公，团队用书面工单取代了走廊里的交谈，这本是明智之举。但他们矫枉过正了。任何人的任何想法都变成了一个待办条目。那些排在最底部、几个月内都轮不到的条目也被详细估算。梳理会议覆盖了整张清单，而不是下一小段。结果是一份看似详尽、实则多是噪音的待办列表，以及一个把「书写工作」误当成「理解工作」的团队。
去精炼那些过于遥远、尚不稳定的条目，等到真正动工时细节早已过时。
把估算当成承诺，让所有人都不愿拆分或重新排序条目。
任由待办列表膨胀，却从不移除那些已不再反映产品目标的条目。
真正解决问题的做法
对产品待办列表及其排序负责的产品负责人重新接管了清理工作。团队一起商定了更轻量的节奏，以及更清晰的梳理目的。
梳理顶部，而非全部。 他们把梳理集中在最有可能进入接下来一两个冲刺的条目上，把靠后的条目留作粗略的占位。
让条目「就绪」，而非「完美」。 当开发者理解到足以有把握地对一个条目作出预测时，它就算就绪了，而不是等到每个字段都填满。
毫不留情地清理。 凡是三个月未动、且不再服务于产品目标的条目一律归档。待办列表降到了一百条以下。
以简短而频繁的小段进行梳理。 每周两次、每次三十分钟、开着摄像头、一次只讨论一个条目的会议，取代了那场马拉松式的会议。
三个冲刺之内，规划时间缩短了，预测更可靠了，冲刺中途的意外也大幅减少。教训并不是梳理可有可无，而是梳理是一场旨在就下一步工作达成共识的对话，而不是一座需要永远打理的待办列表博物馆。
如果你的团队正淹没在一份增长速度快过交付速度的待办列表里，XNM 的项目集与项目交付咨询服务 可以帮助你建立让工作保持清晰、团队持续前进的梳理习惯。