Sprint 需求梳理会

开场，会议目的(3min)

对下阶段的需求做一个讨论、澄清、细化的一个活动，希望通过这个活动，使得团队能对后续阶段的需求能有一个共识，尽量避免团队因为对需求理解的不一致所导致的各类问题，并帮助团队在下个迭代开始的时候更快进入开发状态。

会议主题

    1. PO 需求讲解 (8min)

        PO介绍项目背景，整体需求以及整个 项目最终需要达到的目标，使整个Scrum团队的成员有一个统一的愿景。

    2. 用户故事讨论和分解(1hr)

        PO需要向团队解释用户故事，解释完以后团队可以进行用户故事的讨论。讨论过程中如果发现用户故事过大，就需要进行分解。比如登录的界面该如何显示，后台API该如何对接，登录时的错误信息该如何显示等等。这个时候我们要做的就是将用户故事细化分解，使每一个细化后的工作项都可以在一个sprint周期内完成。

     3. 完善验收标准 (15min)

        用户故事分析并拆解完以后，我们要做的就是完善用户故事的验收标准，这个工作由PO完成，开发团队以及敏捷教练为辅助。只有明确了验收标准，开发团队才能有的放矢，迭代验收的时候PO也才能根据具体的验收标准进行验收。

    4. 优先级排序及工作量评估 (35min)

        验收标准完成以后，就可以排定用户故事的优先级。在backlog列表中，优先级的大小与在backlog中的位置相关。优先级越高的用户故事处于backlog的最上面，以此往下优先级越来越低。

        通常选定一个工作量为1， 其他工作量与之相比较，相应的为1，2，3，5，8，N.....

        需要注意的是在整个工作量评估的过程中，PO没有决策权，真正的决策权在团队的手上，大家协商一致，最终达成共识。

会议总结

PO提供的用户故事往往是站在他的角度觉得已经拆分，细化了，但对于Scrum 团队来讲，这类用户故事内容并没有细化到一个可以单独完成的最小工作单元。这时候就需要团队和PO一起将用户故事细化分解成一个一个独立的工作项。

一定一定要完善验收标准，统一完成的定义，不然你会发现每个人对完成的定义都不一样。

最后需要注意的是工作量的评估是有团队决定的，PO 可以提出意见，但最终决定权在团队受伤，大家协商一致，最终达成共识。