会议前准备及团队背景说明：
1、我们团队采用的是双PO模式，在进行需求梳理会之前，团队PO会和客户PO确认需求的紧急程度和价值大小，根据客户反馈的紧急与否或价值高低，PO会将这些需求的优先级进行重新排序。然后再召开需求梳理会议。
2、需求说明文档会提前1～2天发给团队成员（开发、测试）
3、背景及方式说明
团队成员：10个，包括本地➕省外成员（省外人员是H5人员）
方式：视频会议+现场会议
迭代周期：10个工作日
议程设计及引导过程：
1、会议开始时，PO快速过一遍产品代办列表(excel形式)，按照团队的规模和之前的数据，我们每次迭代完成（15左右的需求），PO会重点说明一下并提醒团队客户PO重点关注或需要紧急上线的需求。——15分钟
引导：说明会议的目的——为了让大家对需求有一个了解，避免后期反攻，所以组织大家来对需求进行梳理。首先请我们PO来讲解一下我们接下来需要开发的大概内容及需要重点保障的需求。
2、澄清、评估工时
2.1、对团队成员进行分组：按照功能进行分组，原生一组（安卓、IOS）、前端H5一组、后端java开发一组、测试人员一组（团队暂时无法做到全栈）
引导：分组介绍——为了方便一会的评估，大家先按照职能角色进行分组，然后进行汇总讨论，给出每个故事的规模及是否紧急重新排定优先级。我们按照预先排定的优先级进行需求说明：
2.2、产品经理（产品经理对需求细节更为了解）按照需求优先级对需求内容逐个讲解，产品讲解完成后，对开发存在的疑问点进行解答。——平均每个需求澄清➕回答问题需要7分钟
引导：大家对澄清内容是否存在疑问点，如果存在，具体是什么呢？
2.3、需求评估：解答完成后，请需求涉及到的各组进行讨论，需求对应功能需要花费多长时间，以人天为单位。然后请组长来给出需求的时间。——发散
汇总各小组的时间，筛选去掉重复时间（后端java和前端H5或原生是可以并行开发的），然后得出故事的一个规模（5分钟）——收敛
2.4、关于DOD：产品经理在澄清需求后会给出一个初步的DOD（会议前已具备DOD），团队成员对DOD进行完善，确认。——2分钟
引导：让我们看一看如何来演示这个需求，在什么情况下，代表我们已经可以交付该需求？大家如果有补充请及时提出
一个需求总共需求：15分钟
我们一般会评估20个左右的需求（超出迭代计划5个）至少3个小时，因为远期的需求可能寻在不明确的地方无法给出大概的时间评估
3、根据需求规模评估，PO与团队重新排定发布计划，并与团队确认——10分钟左右
引导：这是我们调整后的需求优先级及功能规模，大家是否都已明确？
成果：
经过调整后的产品代办列表，需求具有优先级、每个需求大概的规模、预计的版本时间
自我反馈：
每次会议的时候都有一种计划赶不上变化的情况。所以控制会议时长非常重要，一般每次会议会持续3个小时左右，我们会在一个半小时的时候休息10分钟。我们之前也尝试过一口气开完3小时的会，但是到后面团队会疲倦，效率会非常低，为了完成而去完成，对于后面的需求可能会议结束后后他们仍是不清楚的情况。
对于需求拆分的粒度，我们刚开始是一个需求对应一个故事，这会导致迭代形成小瀑布方式，大需求在迭代最后一天提测或者更严重一点到迭代结束为止需求让处于开发状态，后来我们的拆分标准改为：每个故事最长时间不超过5天，这样的话会给测试预留一些时间。
