产品列表梳理会（Backlog Refinement Meeting）。
Refinement 这个词是加工、提炼的意思，在scrum里，其实就是对下阶段的需求做一个讨论、澄清、细化的一个活动，希望通过这个活动，使得团队能对后续阶段的需求能有一个Common Understanding，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态，它一般是发生在下个迭代开始前的一段时间里。中文一般叫做产品待办列表梳理会议（product backlog Refinement）。
Scrum标准的5个活动里面是没有梳理会的，需求的梳理往往放在计划会里。但是对于刚开始转型敏捷的团队，需求梳理如果放在计划会里，往往会造成迭代计划会时间过长，或者无法准时开始迭代等等问题，所以梳理会才会被独立出来。如果团队成熟以后，需求梳理可以直接放到计划会里进行。
Refinement活动还是比较花费团队时间的，那么对于时间总是不够的开发团队来说，花费多少时间来做Refinement是比较合理的呢？
推荐整个迭代花费在Refinement会议的时间占总时间的5%，比如一周的迭代，Refinement通常在2个小时左右。
需求的梳理其实不仅仅只发生在每个迭代的Refinement的会议上，它其实应该是贯彻发生在整个软件开发的全过程中。只是在Refinement 会议上做了最大量的需求梳理的工作，然后从sprint的开始，花费在需求梳理上的时间会慢慢减少，花费在软件设计开发上的时间慢慢增加，到了sprint得后期就慢慢没有了需求方面的工作而只剩下开发上面的工作了。
Refinement并不只是梳理下个迭代的开发内容，而是下个阶段重要的开发需求，Refinement梳理的内容范围往往会大于下个迭代能完成的范围。
在某些变化比较快的领域还会出现Refinement的内容并没有出现在下个迭代开发列表中的情况。
简单的来说，Refinement目的就是让我们Backlog里的Story更加DEEP，DEEP的意思是：
Detailed Appropriately
Emergent
Estimated
Prioritized
具体操作方式如下图。
梳理会的主题主要解决以下3个问题：
1. 用户故事讨论，分解用户故事
我们知道用户故事是由PO编写完成，他/她通过采集用户需求或者市场调研不断充实完善用户故事。针对每一个用户故事，在backlog refinement meeting的第一件事情就是PO需要向团队解释用户故事，解释完以后团队可以进行用户故事的讨论。讨论过程中如果发现用户故事过大，就需要进行分解。比如：
可以看出，这类用户故事内容并没有细化到一个可以单独完成的最小工作单元。比如登录的界面该如何显示，后台API该如何对接，登录时的错误信息该如何显示等等。这个时候我们要做的就是将用户故事细化分解，使每一个细化后的工作项都可以在一个sprint周期内完成。
如何分析用故事可以参考：用户故事分析。
2. 完善验收标准
用户故事分析并拆解完以后，我们要做的就是完善用户故事的验收标准，这个工作由PO完成，开发团队以及敏捷教练为辅助。其书写格式可以参考：如何书写验收标准。
只有明确了验收标准，开发团队才能有的放矢，迭代验收的时候PO也才能根据具体的验收标准进行验收。
3. 排定优先级，评估工作量
验收标准完成以后，就可以排定用户故事的优先级。大家可以参考：用户故事优先级排定。
在backlog列表中，优先级的大小与在backlog中的位置相关。优先级越高的用户故事处于backlog的最上面，以此往下优先级越来越低。
用户故事被细化成一个个工作项后，接着我们要做的就是评估每一个工作项的工作量。通常scrum中工作量的计量方式通过斐波那契数列标定，即1，2，3，5，8，13，21，34，55。在实际的项目中，我们通过扑克牌估点。针对每个工作项，开发团队的每个人都给出自己的扑克点数，最后经过大家协商讨论，给出最终的评估。需要注意的是在整个工作量评估的过程中，PO没有决策权，真正的决策权在团队的手上，大家协商一致，最终达成共识。
Refinement（grooming）并不是一个在scrum下才有的新的概念，它和传统的软件开发流程中的产品需求评审非常像，不过它们还是有些区别：
发生的时间不同
需求评审往往发生在整体开发之前，一次性的居多；Refinement可以分次开展，一般发生在每个迭代中间靠后阶段
产生的方法不同
需求评审是由产品单方面给出，其他人提意见；Refinement是期望所有人一起来完成
存在的目的不同
需求评审是上下游交接的手段；Refinement是让大家达成common understanding的方式
