为了保持产品待办事项（product backlog）的整洁有序，我们需要召开product backlog refinement会议（有时也叫product backlog grooming）。这个会议是在一个sprint快要结束的时候召开的，以确保下一个sprint的待办事项都准备好了。
在这个会议上，团队和产品负责人（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。