团队需求梳理会
时间：2020-10-26
地点：三楼Meeting Room C
会议名称：XXX项目需求梳理会
背景：当前项目是一个医院管理系统，最近由于COVID-19的影响，PO那边又有一些大的紧急的需求进来，同时需要对后期需求优先级进行调整。所以召开了一次需求梳理会。同时对下阶段的需求做一个讨论、澄清、细化。希望通过这个活动，使得团队能对后续阶段的需求能有一个Common Understanding，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态。
议程设计:
基于Refinement的目的，我们需要把backlog里的story更加DEEP（Detailed appropriately，Emergent，Estimated，Prioritized），同时整个Refinement的过程按照发散和收敛的过程进行。
发散
在发散阶段我们针对目标story做发散思维的讨论，尽力考虑到各个方面的问题、假设、困难，防止专家思维的局限，这是个头脑风暴的过程。
发散的过程中注重以下几个事项：
暂缓对别人观点的评论
鼓励异想天开的想法
借“题”发挥，别人的观点上继续延生
专注在story上，不要偏离主题
图文并茂，鼓励使用可视化的方式
做加法，Ideal越多越好（先不关注Ideal的质量）
分组讨论
为了更高效的完成这个Refinement，在发散和收敛阶段我们都运用了分组讨论，具体操作方式如下：
1. 把团队随机拆成2-3个group，每个group分到一个高优先级的story来讨论。围在一个A0的大纸前，讨论这个story的S、Q、A即：
Scope：team为了完成这个需求到底要做哪些事，不做哪些事情
Question：任何对这个需求不清楚的问题
Assumptions：为了做这些事的前提假设，可能是成立的，也可能是不成立的
2. 团队成员把讨论中能想到的SQA记录在纸上，PO巡视各个小组，并回答纸上的问题。
在这个过程中团队有很多疑问和假设，PO在团队讨论的过程中随时解答团队的疑问和澄清假设，没能当场澄清的，团队和PO记录下来，在下个迭代Planning Meeting前完成澄清。
3. 讨论差不多的时候，每个group留一个人，其他人交换到其他group里去，留下的人负责给新加入这个组的人做介绍，大家讨论并继续完善这个话题。
4. 最后每个group里找到一个可能对这个story了解最少的人给整个team介绍最终SQA的内容。
收敛
在充分发散的基础上我们开始做收敛，并得出Refinement的最终结果。
在收敛过程中运用了以下方法：
明确了产出结果形式
投票找到公认的重点
时间盒
心得:
及时定期的做需求梳理会是确保Sprint Planning会议更顺利运行的最佳方法之一。它能改进了产品待办事项列表的质量，使每个参与其中的人都更加熟悉所要求的内容，并且使自信地达成Sprint承诺变得更加容易。
