原文作者：Mike Cohn

为了保持产品待办事项（product backlog）的整洁有序，我们须要召开product backlog refinement会议（有时也叫product backlog grooming）。这个会议是在一个sprint快要结束的时候召开的。以确保下一个sprint的待办事项都准备好了。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

在这个会议上，团队和产品负责人（product owner）一起讨论高优先级的待办事项。团队能够趁此机会提出问题（这些问题通常在spring计划会议上也会冒出来）：

• 假设用户在这里输入无效的数据，怎么办？
• 全部的用户都被同意訪问这部分系统吗？
• 假设……。会怎么样？

通过较早地提出这些问题。特别是当产品负责人预先没有想到这些问题的时候，他就有机会去进一步探寻答案。

假设这些问题在sprint计划会议上才被第一次提出来，并且太多问题得不到解答。一个高优先级的待办事项必定就被搁置起来。也就无法排进sprint被实施了。

在product backlog refinement会议上，这些问题无须一一解决。

产品负责人仅仅须要解决当中基本的。让团队有信心觉得那个需求在即将召开的sprint计划会议上能够被充分讨论就可以。

这么看。与其说product backlog refinement会议致力于全面解决这个问题，不如说它是一个检查点。

我喜欢在当前sprint结束的前3天召开product backlog refinement会议。这样就能给产品负责人足够的时间去解决会上指出的问题。有些团队不喜欢这样（每一个sprint进行一次backlog refinement）。他们更适应于每周花一些时间开短会的节奏——这当然也是能够的！

不像Scrum里的其它会议，我不觉得product backlog refinement会议须要团队全体成员一起參与。

试想一下。在sprint结束前3天。假设把整个团队都聚起来开会，而此时非常可能正是有人超级忙的时候——假设他被迫參会，他就不得不加班才干完毕当前sprint的工作任务了。

我更倾向于撇开这种团队成员来开这个会。

仅仅要不出现每一个sprint都是相同一些人不參会的情况，我觉得，团队里能有大概一半人參加product backlog refinement会议就能够了。当然还要加上产品负责人和Scrum Master。