组织在引入Scrum框架后，会逐步了解到Scrum的团队组建、角色分工、交付工件和相关会议/活动等内容。随着框架的逐步落地，定义清楚相关角色、明确要交付的工件之后，如何通过Scrum的“4+1”活动来进行迭代管理并达成预期的目标？就成为团队必须要面对的问题。这里所谓Scrum“4+1”活动就是指每日站会、迭代计划会、迭代评审会、迭代回顾会和迭代梳理活动，有的团队通也会把迭代梳理活动作为其中一个会议，称之为迭代梳理会。所以我们也会听到有Scrum 5个会议的叫法，为了进一步的阐述和讨论，我们在此统一称之为为5个会议，接下来我们将逐一进行解读。
会议之一：迭代梳理会，Scrum指南虽然没有对梳理会有提出明确的定义，但是在Agilealliance（敏捷联盟）官网中对其进行了解读：
Backlog refinement is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery. This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity.
待办事项梳理是指产品负责人和部分或全部团队其他成员审查 待办事项上的项目，以确保待办事项包含合适的待办事项，它们经过优先级，并且项目在待办列表的顶部，且已准备好交付。此活动定期发生，可能是正式安排的会议或正在进行的活动。
如何让团队成员清楚的认识并开好这迭代梳理会，提前对下轮迭代的任务进行准备，我们尝试从以下几个方面对其进行解读和说明。
会议目的
首先是要明确会议的目的，迭代梳理会的目的是PBI列表更新，进行下轮迭代的需求澄清，提前识别风险和问题。
会议时间
当前迭代进行中、下轮迭代开始前。
会议时长
对于为期2周的迭代来讲，时长控制在1~2小时，不要超过2小时。
会议角色
那么迭代计划会都有哪些角色参与呢，他们的工作如何分工？
PO，主导者
1. 讲解PBI的需求（故事）变更
2. 澄清故事，带领团队完成初步估算
3. 会后就需求问题进行跟踪处理
4. 必要时，可延展介绍后续的产品规划及方向
SM，参与者
1. 提醒团队成员准时与会
2. 会议问题记录，责任到人
3. 做好风险识别和问题跟踪管理
4. 会议过程控制，避免陷入长时间讨论
Team，参与者
1. 针对PO的故事提出疑问，确保理解PBI中需求
2. 认可故事的价值、优先级排序
3. 进行故事点估算
4. 确保理解下轮迭代任务及产品后续规划
准入准出
会议准入
1. 变更后的PBI列表
2. 用户故事（需求）按照优先级排序
3. 完成验收标准
会议准出
1. 更新后的PBI列表
2. 过程中的风险、问题记录清单
会议流程
1. PO讲解需求的变更点
2. 团队参与需求讨论，明确下轮迭代需求细节
3. 进行PBI的更新（优先级调整、AC更新等），包括清理不再进行开发的用户故事
4. 风险项、问题记录
综上所述，我们从梳理会的目的、时间安排、时长，参与角色、准入准出以及流程方面给出了解读，虽然方法和流程都是通用的，但是通用的流程、同样的方法，有的团队就会做得比较高效，有的团队却经常超时、达不成目的。究其原因，真正要把评审会开好，除了会前的充分准备以外，会议过程的引导也至关重要。对于梳理会来讲，围绕PBI进行下轮迭代要做的需求澄清是我们的目的，所以开展正确的引导，避免大家在过程中太过发散、无法收敛，导致会议超时，影响参会者的体验。
实际上任何一个新的方法、框架在落地过程中，一定会有各种各样的问题，很难立马达成我们想要的结果，所以Scrum的会议本身也是在实战过程中迭代改进的，不是靠理论就能做好的，纸上得来终觉浅，绝知此事要躬行。希望团队能够基于实际问题出发，大家一起讨论、寻求解决方案，在实践中逐步迭代、达到预期的目的。
