需求梳理会

需求梳理会

目标及定义：对下阶段的需求做一个讨论、澄清、细化的一个活动。希望通过梳理会，使得团队能对后续阶段的需求能有一个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承诺变得更加容易。