Backlog 梳理：谁来做？何时做？怎么做？

“梳理Backlog”，是指定期用心检查和关心产品的backlog，这样它就不会变得像杂草丛生、无人搭理的花园一样丑陋不堪和难以处理。尽管这不是Scrum 的正式流程，然而，Ken Schwaber 推荐每个sprint 中留出5% 的时间来做这件事情。最近，在 Scrum Development 邮件组中对此话题进行了讨论，提到了该流程的优势、劣势和疑问。

Charles Bradley 提到：在他所在的团队中，梳理 backlog 的最佳时间，是下个 sprint 启动的三个工作日之前，而且是团队全体成员参加。Charles 列出梳理 backlog 的如下好处：

• 在估算和开始工作之前，让人们有更多时间消化新的用户故事。
• 有更多时间优化设计。
• 有更多时间研究、吸收需求中的问题和障碍。
• 强迫产品负责人为 Sprint 规划会议好好做准备。
• 如果产品负责人发现某些新出现的用户故事，他可以采取一些纠正措施。

Mark 回应认为：他在这种方法中看到多个问题。在Mark 看来，这么做会让团队偏移注意力去关注新的工作，而不是完成当前sprint 中的故事。他补充道：如果整个团队都参与到梳理过程中，当前的sprint 将可能会因此受到不良影响。Mark 反复强调：在梳理backlog 上耗费太多时间会降低生产力，而且这些会议也不应被看做设计会议。梳理的目的在于得到用户故事刚刚够的细节，这样规划会议就可以更加有效率。

同样地， Adam Sroka 也提出：在规划会议前再开一个会，以帮助规划会议顺利进行，尽快这种做法他觉得没什么问题，但是团队不应该增加花在规划活动上的“净时间 (net time)”。应该遵守这个规则：每两周开一次、每次 4 个小时。用梳理 backlog 打掩护，团队能希望弥补他们sprint 规划会议的不足，这么做是不对的。

Jim Schiel 回应了对于梳理会议的疑问，他指出：

我们把人们从 sprint 之内的开发工作中拉出来，对于人们对此的担心，我完全理解。但是： 1. 允许人们花点时间思考未来是有好处的；有时，想点不一样的事情能够让他们在回到自己的任务上时更有效率。
2. 讨论即将面对的故事是很有效的，可以帮助团队先了解在下个 sprint 规划会议中要解决的问题。

Jim 又补充道：他希望在整个 sprint 中都能召开梳理会议，而不仅仅是在快结束时进行。他推荐每周花几个小时来做这个事情。

在当前sprint 中用几个小时来梳理后面的backlog ，这么做不应影响开发人员的工作效率，而且应该对团队有所帮助； Ron Jeffries 同意这样的想法。

Jussi Menonen总结了讨论的大方向，而且提到在他们的实际情况中，梳理会议非常有帮助。

我们曾尝试在 sprint 规划会议中梳理并收集需求，但是没有效果。我们从未得到足够的细节，而且经常实现了错误的东西。

由于他们过去在规划会议中花费了太多时间，而且经常实现错误的行为，他们就开始在每个 sprint 之中召开一个小时的梳理会议。这么做似乎对他们很有效。

Roman Pichler 提到让整个团队都参与的巨大好处所在。在 Roman 看来：

大家一起协作梳理产品 backlog，这可以在 Scrum 团队内部、以及团队与利益相关者之间创建一种对话的气氛。这么做消除了“做业务的”和“做技术的”二者之间的鸿沟，也消除了交付错误产品的浪费，避免了沟通的错误，让大家的目标保持一致。需求不再是转交给团队，团队成员也成为其创建者之一。这让需求更清晰，提升 Scrum 团队共同的知识和创意，并让人们真心拥护，产生主人翁意识。

因此，大家形成共识：梳理会议应该进行，而且整个团队都应该参加。建议同时指出，不应让这些会议时间过长。推荐的时间限度是每周不要超过几个小时。

查看英文原文： Backlog Grooming: Who, When and How