标签:
为了保持产品待办事项(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。
标签:
原文地址:http://blog.csdn.net/happydeer/article/details/50756413