“梳理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之内的开发工作中拉出来，对于人们对此的担心，我完全理解。但是：
- 允许人们花点时间思考未来是有好处的；有时，想点不一样的事情能够让他们在回到自己的任务上时更有效率。
- 讨论即将面对的故事是很有效的，可以帮助团队先了解在下个sprint规划会议中要解决的问题。
Jim又补充道：他希望在整个sprint中都能召开梳理会议，而不仅仅是在快结束时进行。他推荐每周花几个小时来做这个事情。
在当前sprint中用几个小时来梳理后面的backlog，这么做不应影响开发人员的工作效率，而且应该对团队有所帮助；Ron Jeffries同意这样的想法。
Jussi Menonen总结了讨论的大方向，而且提到在他们的实际情况中，梳理会议非常有帮助。
我们曾尝试在sprint规划会议中梳理并收集需求，但是没有效果。我们从未得到足够的细节，而且经常实现了错误的东西。
由于他们过去在规划会议中花费了太多时间，而且经常实现错误的行为，他们就开始在每个sprint之中召开一个小时的梳理会议。这么做似乎对他们很有效。
Roman Pichler提到让整个团队都参与的巨大好处所在。在Roman看来：
大家一起协作梳理产品backlog，这可以在Scrum团队内部、以及团队与利益相关者之间创建一种对话的气氛。这么做消除了“做业务的”和“做技术的”二者之间的鸿沟，也消除了交付错误产品的浪费，避免了沟通的错误，让大家的目标保持一致。需求不再是转交给团队，团队成员也成为其创建者之一。这让需求更清晰，提升Scrum团队共同的知识和创意，并让人们真心拥护，产生主人翁意识。
因此，大家形成共识：梳理会议应该进行，而且整个团队都应该参加。建议同时指出，不应让这些会议时间过长。推荐的时间限度是每周不要超过几个小时。