Facilitate团队进行至少1次Product Backlog Refinement/Grooming数据项目需求梳理会

参会人员：

Product Owner：负责讲解需求，回答关于需求细节与优先级的问题

Scrum Master：负责设计讨论议程，计时、控制场面

Team团队：负责提问、评估技术风险、对需求给出建议、澄清细节、给PO提供方案选择、将需求分解为验收条件

梳理范围：

Refinement并不只是梳理下个迭代的开发内容，而是下个阶段重要的开发需求，

Refinement梳理的内容范围往往会大于下个迭代能完成的范围。特别是数据分析项目需求变化比较快的领域，还会出现Refinement的内容并没有出现在下个迭代开发列表中的情况

梳理会流程设计如下：

1、PO需求讲解

2、产品待办列表与清晰度梳理

3、用户故事分解

4、产品待办列表优先级重排

5、紧急逻辑修改需求

6、临时数据提取需求

过程：

1、[endif]PO需求讲解

首先PO对整体需求和整个项目需要最终达到的目标进行了讲解，使得整个Scrum团队的成员都获得统一的目标认知

2、产品待办列表与清晰度梳理

把这些需求在excel文档上记录下来，在excel上创建三个tab：范围，疑问和假设

范围：记录下要做和不需要做的内容以及分解后的验收条件。

假设：记录下目前实现方案的依赖和假设，包含当前确定的共识和潜在的以后可能需要改变的方案。

疑问：记录下PO自己目前也无法回答的疑问，在梳理会后需要做进一步澄清。

将Team团队分成两个小组，小组成员讲解自己的理解，每半个小时，每个小组留下最熟悉和最不熟悉的各一个人，其余人交换小组去讨论，每组留下的人负责给其他移动过来的人讲解目前的讨论结果，解答问题一起讨论。

3.Team对用户故事进行分解，并进行工作量评估

最后推荐一个人担任组长，该组长和最熟悉的人一起分解任务，其余人可以自行决定加入哪组，任务分解的差不多的时候，我会让大家回顾一下我们已经完成的故事点，对于用户故事太大的，我们会建议PO进行后续分拆，进一步澄清以及调整优先级，分解后的任务的颗粒度达到1-2天的工作量，同时该功能能够开发，测试，演示以及满足DoR，形成文档

4.产品待办列表优先级重排

最后PO对需求进行优先级排序，以备在sprint计划会上挑选出优先级高的用户故事进行开发，红色是最紧急和重要的，绿色的是重要的，其他是次重要的

5、紧急需求新增约束

数据分析项目需求变化比较快，还会出现Refinement的内容并没有出现在下个迭代开发列表中的情况，限制每月只能新增1-2个紧急需求，但必须是逻辑清晰，复杂度中等偏下的需求。需求模板如下：

6、临时数据需求申请表

五大要素必须全： 谁+什么时间+要什么数据+什么时间使用+用来干啥

心得总结：

1、梳理会开完以后每个人都能理解自己该做什么需要做什么，要做到什么程度

2、需求梳理会的核心就是用户故事的设计，应该满足INVEST原则：

Independent 独立的：

尽可能避免故事间的相互依赖，因为这会影响到故事优先级和开发计划的编排

Negotiable 可讨论的：

Valuable to

Purchasers or Users 对客户或用户有价值的：

对客户或用户有价值的最好方法是让客户自己来编写故事

Estimable 可估计的：

对于开发人员而言，故事是需要能够估算大小的，否则很难把它们安排到开发计划当中。一般会有如下三个原因导致任务不可估计：

1. 开发人员缺乏领域知识

2. 开发人员缺少技术知识

3. 故事太大了

Small 小的：

正如上文提到，过大的故事需要被拆分成更小的故事以便于估计工作量，而与此同时，如果故事太小，也无助于故事的评估。对于过大的故事，我们需要进行故事的拆分与分割，而过小的故事则需要进行合并。

Testable 可测试的：

故事必须是可测试的。只有成功通过测试才能说明该故事已经被开发完成。