需求梳理会
目标及定义：对下阶段的需求做一个讨论、澄清、细化的一个活动。希望通过梳理会，使得团队能对后续阶段的需求能有一个commonunderstanding，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态。它一般是发生在下个迭代开始前的一段时间里。中文一般叫做产品待办列表梳理会议（productbacklog refinement）。
基于Refinement的目的，我们需要把backlog里的story更加DEEP（Detailedappropriately，Emergent，Estimated，Prioritized），同时整个Refinement的过程按照发散和收敛的过程进行。
与会者：Scrum Master、团队所有成员 、产品负责人
准备工具：荧光笔、贴纸、白板和挂纸板
准备工作：提前分发待梳理的下一阶段待梳理产品待办列表，团队成员可先行了解，减少在梳理会中沟通成本，增加会议效率。
议程设计：
会议时间（150分钟）
1，启动梳理会 （5分钟）
SM强调梳理会的定义与目的。
2， 描述需求（10分钟）
将用户故事逐条贴在在白板上。
PO对复杂条目进行讲解，描述需求。
3，需求发散（30分钟）
在发散阶段我们针对目标story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个头脑风暴的过程。
发散的过程中注重以下几个事项：
暂缓对别人观点的评论
鼓励异想天开的想法
借“题”发挥，别人的观点上继续延生
专注在story上，不要偏离主题
图文并茂，鼓励使用可视化的方式
做加法，Ideal越多越好（先不关注Ideal的质量）
4,分组讨论 (60分钟)
为了更高效的完成这个Refinement，在发散和收敛阶段我们都运用了分组讨论，具体操作方式如下：
把团队随机拆成2-3个group，每个group分到一个高优先级的story来讨论。围在一个白板前，讨论这个story的S、Q、A即：
Scope：team为了完成这个需求到底要做哪些事，不做哪些事情
Question：任何对这个需求不清楚的问题
Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的
团队成员把讨论中能想到的SQA记录在纸上，PO巡视各个小组，并回答纸上的问题。
在这个过程中团队有很多疑问和假设，PO在团队讨论的过程中随时解答团队的疑问和澄清假设，没能当场澄清的，团队和PO记录下来，在下个迭代PlanningMeeting前完成澄清。
讨论差不多的时候，每个group留一个人，其他人交换到其他group里去，留下的人负责给新加入这个组的人做介绍，大家讨论并继续完善这个话题。
最后每个group里找到一个可能对这个story了解最少的人给整个team介绍最终SQA的内容。
5，收敛阶段（40分钟）
在充分发散的基础上我们开始做收敛，并得出Refinement的最终结果。
在收敛过程中运用了以下方法：
明确了产出结果形式/投票找到公认的重点/时间盒
6，会议结束（5分钟）
总结结果，更新产品待办列表。
心得：
需求梳理会的目的是Refinement目的就是让我们Backlog里的Story更加DEEP，为了解决“用户故事讨论，分解用户故事/完善验收标准/排定优先级，评估工作量“，由团队一起来完成，使大家达成commonunderstanding。从而确保SprintPlanning会议更顺利运行的最佳方法之一。它能改进了产品待办事项列表的质量，也使使自信地达成Sprint承诺变得更加容易。
