上一篇文章里我们聊到在使用鲸舟时，产品经理或者产品负责人（艾米莉）如何去定义用户故事，简单回顾一下：在鲸舟中，我们使用三段式来定义用户故事，即“作为……希望……以便……”。通过这种形式描述故事，可以准确的传达需求的定义。
另外，在鲸舟中，在定义用户故事的同时，需要定义验收标准。
接下来，我们开始进行敏捷研发中最重要的一个环节——需求梳理会。
需求梳理会的目的：
- 提前给团队成员讲解故事，讨论和澄清需求与设计疑问，预留时间解决问题，让正式迭代计划更高效、合理。
- 让团队成员 关心产品全貌，而非只关注自己本身的工作，提升团队协作效率。
- 由团队来估算故事大小，量化团队容量。
需求梳理会通常是在迭代前3~4天召开，一般会在正式计划前，预留几天解决会上绝大不清的问题。
主要参会人员由PO、DM、Team.
艾米莉调整产品Backlog的故事优先级
按迭代日历，路飞本周四会召集团队举行需求梳理会，周三商务艾米莉打开工具，选择“待规划Backlog”，把近期已拆开并书写完成的故事列表打开，上下拖动故事以排列优先级，靠上面的故事优先级越高。
团队对争议故事进行估点
周四上午的需求梳理会上，艾米莉打开工具，选择“待规划Backlog”，把已按优先级排序的故事列表打开，从第1个故事开始讲解，讲解完成后，大家就故事细节进行充分沟通与答疑后，整个团队开始估点。在故事细节梳理清洗后，团队对第1个故事集体给出了3点大小。
艾米莉在鲸舟中记录了该点数。
tips：团队如已规划好模块信息，可提前或在梳理会上设置好故事模块和标签信息。
需求梳理会修改验收标准
艾米莉在讲解完第2个故事后，团队在进行估点得过程当中，发现第2个故事得验收标准描述不合理，艾米莉修改了验收标准，团队做第2轮估点，估点结束后，录入点数。
需求梳理会上记录有争议或待澄清得列表
艾米莉在讲解完第3个故事后，路飞和刀哥对于数据设计和存在较大争议，一时间难以达成一致。路费为了提高梳理会得效率，该故事暂不估点，并让艾米莉把争议点记录在故事的备注中，会后两人再及进行详细讨论，并给出最终结果。
会后路飞与刀哥就表结构设计达成一致，邀请艾米莉与乔乔一起对故事进行重新估点，并把点数录入鲸舟。
