Product Backlog Refinement

产品backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。

区别于瀑布开发模式的一开始就把需求全部写出来进行评审，敏捷开发模式下，会持续地去做Product Backlog Refinement，在每个迭代中都会去做。对于一周的迭代，差不多需要投入2个小时的时间进行需求梳理，梳理的目标不是下个迭代的需求，而是将要做的最重要的需求。梳理的目标，就是为了让我们的产品代办列表更加符合DEEP原则。

Detailed appropriately  适当详细

Emergent  紧急的

Estimated  估算的

Prioritized  排好优先级的

需求梳理，通常分为两个部分：发散和收敛。

发散的意思就是在对一个story做梳理的前期，我们需要针对目标story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个头脑风暴的过程。

在充分发散的基础上我们就要开始收，这样我们才能拿到需求梳理的最终结果，这就是收敛的过程。

我们怎么去做需求梳理呢？可以用SQA的方法，大家一起回答目标story的"Questions"，"Scope"，"Assumptions"三个问题来澄清我们的需求。

Question：任何对这个需求不清楚的问题

Scope：team为了完成这个需求到底要做哪些事，不做哪些事情

Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的

这里会有很多疑问和假设，产品负责人需要在团队讨论的过程中随时解答团队的疑问和澄清假设，不能当场澄清的，团队和产品负责人需要会后带回去，在下个迭代计划会前完成澄清。

发散和收敛的讨论是一个非常费时的过程，那我们该怎么更高效的完成这个refinement呢？

比较推荐的做法就是分组来讨论：

3人一组，把团队拆成多个group，每个group分到一个高优先级的story来讨论，讨论这个story的S、Q、A。

团队成员把讨论中能想到的SQA记录在纸上，产品负责人巡视各个小组，并回答纸上的问题。

讨论差不多的时候，每个group留一个人，其他人交换到其他group里来，留下的人负责给新加入这个话题的人做介绍，大家讨论并继续完善这个话题。

最后每个group里找到一个可能对这个story了解最少的人给整个team介绍最终SQA的内容。

全部做完后，完成此次需求梳理活动。