Refinement 这个词是加工、提炼的意思，在scrum里，其实就是对下阶段的需求做一个讨论、澄清、细化的一个活动，希望通过这个活动，使得团队能对后续阶段的需求能有一个 common understanding ，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态，它一般是发生在下个迭代开始前的一段时间里。中文一般叫做 产品待办列表梳理 会议（product backlog refinement）。
其实refinement在之前还有一个名字，叫做 grooming ，但据说这个词的意思在英国会令人不太舒服，所以后来scrum联盟就改用了refinement这个词。如果你发现还有人在使用grooming，你可以告诉他/她，"你out了, _ "
refinement（grooming）并不是一个在scrum下才有的新的概念，它和传统的软件开发流程中的产品需求评审非常像，不过它们还是有些区别：
简单的来说，refinement目的就是让我们backlog里的story更加 DEEP ，DEEP的意思是：
具体操作方式如下图。
发散的意思就是在对一个story做梳理的前期，我们需要针对目标story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个脑暴的过程。 发散的过程中有几个小tips：
为了更好的引导这个脑暴的过程，我们常见的指导分析方法有 FURPS+ 和 SQA，这两个方法下面单独介绍。
在充分发散的基础上我们就要开始收，这样我们才能拿到refinement最终的结果，这就是收敛的过程。 为了帮助收敛，我们常用的手段有：
“FURPS+”更像一个checklist，它能提醒我们在发散的时候要从这些角度去思考，避免有大块的遗漏。
相对于上面的FURPS+的方法，SQA的方法在我遇到的实际中更加常用和易用。 SQA就是通过大家一起回答目标story的"Questions"，"Scope"，"Assumptions"三个问题来澄清我们的需求。
这里会有很多疑问和假设，PO需要在团队讨论的过程中随时解答团队的疑问和澄清假设，不能当场澄清的，团队和PO需要会后带回去，在下个迭代planning meeting前完成澄清。
发散和收敛的讨论是一个非常费时的过程，那我们该怎么更高效的完成这个refinement呢？ 比较推荐的做法就是分组来讨论：
refinement并不只是梳理下个迭代的开发内容，而是下个阶段重要的开发需求，refinement梳理的内容范围往往会大于下个迭代能完成的范围。 在某些变化比较快的领域还会出现refinement的内容并没有出现在下个迭代开发列表中的情况。
需求的梳理其实不仅仅只发生在每个迭代的refinement的会议上，它其实应该是贯彻发生在整个软件开发的全过程中。只是在refinement 会议上做了最大量的需求梳理的工作，然后从sprint的开始，花费在需求梳理上的时间会慢慢减少，花费在软件设计开发上的时间慢慢增加，到了sprint得后期就慢慢没有了需求方面的工作而只剩下开发上面的工作了。
refinement活动还是比较花费团队时间的，那么对于时间总是不够的开发团队来说，花费多少时间来做refinement是比较合理的呢？ 推荐整个迭代花费在refinement会议的时间占总时间的5%，比如一周的迭代，refinement通常在2个小时左右。
小禾小影
