[Scrum敏捷开发之] Sprint 计划会议详解

Sprint计划会议有三个关键步骤:

但是，为了确保这些目标的确切的达成，需要确保下列工作:

倾听所有人的声音
团队必须审查并详细描述Sprint中所有的用户故事
团队必须能够在Sprint计划会议的时间窗内选择用户故事并对每个Story的effort进行量化 Story Point
该会议的时间窗一般 0.5d / 2w sprint。同样对于评审和回顾会议亦是如此。这样对于一个10d的Sprint，将有1d用于计划和评审。

为了正确的实施，团队必须要避免：

做好Sprint计划的关键有两个方面:

优秀的用户故事编写意味着SM和PO需要共同合作来确保质量，尤其是当团队有了一个新的产品负责人，而他之前没有在Scrum团队或这个Scrum团队中工作过时，这一点更加重要。

规划游戏的使用是必不可少的，因为它有助于促进和激发团队的创造力。通常这时许多团队会问，“为什么不只是谈论用户故事本身呢?”不使用“开放讨论”的关键原因:

这就是在Scrum中使用Games的原因，最通常使用的是 扑克牌游戏。

扑克牌游戏 规则的关键规则可以参考: http://agileinaflash.blogspot.com/2009/07/planning-poker-r.html

这个过程用于完成三件事:

很多时候，对于如何确定一个 point scale 存在分歧。有正当的理由相信，尤其是当团队成员或团队之外的管理人员误用Story Point时。以下是一些需要考虑的要点：

请注意，在是否Story Point应该是绝对的度量标准方面，许多“规模化框架”对此有争议，或有偏差，亦或认为应该在跨团队时仍保持一致。对于Scrum和它的变更来说，这并不重要。Story Point仅仅是为了帮助团队了解可以完成多少工作，以及团队是否在一个又一个Sprint中变得更快速。

最后，在Planning会议中还有一些额外的事情需要考虑:

在Sprint计划会议之前pick User Story
选择那些可以紧密形成一个PI的Story
- 最好是PO头脑中已经有了一些想法
- 该PI 需要记录在"Sprint Objective"以帮助保持关注
进行"扑克牌游戏"时，按照User Stories逐项进行
- 这是最快的方式，因为所有人同一时间专注于同一Story
- 也是最容易的方式，因为同一时间只需要考虑一个Story
确保在第一个Sprint保留一些buffer，毕竟“万事开头难”
确保所有人都对完成这些任务做出承诺 - 在没有得到团队明确的“自信心投票”之前，不要让任何人离开
最终将细化产品待办事项列表，并在此过程中识别潜在的依赖项
- 当需要更新Sprint和PB时——立刻就做。不要错失那些在计划会议中出现的顿悟时刻
- 确保你所使用的工具是简单而有效的，以确保过程如丝般顺滑
最后，确保对Sprint Backlog排优先级，因此开发团队知道第二天应该首先开始哪些用户User Story

通过遵循这些指导方针，你的计划将比任何小组讨论或面试过程更快速、更全面、更准确。

关于缩写：
Product Increment - PI
Product Backlog - PB

如果觉得对您有帮助，烦请动动小手点个赞！这也是对我最大的激励。