Scrum Guide 精读 - 9. Sprint Planning

scrum guide精读。

今天看一看scrum活动中的spring planning。也就是迭代计划会议。

    相信很多团队经历过，Sprint前期一个或者几个冗长的会议，大家对接下来的一个Sprint里面需要做的工作任务进行梳理澄清，一个一个地过需求文档。都哪些功能需要开发，界面设计是怎么样的，涉及到哪些前端或者后端的工作，有经验的团队还会考虑测试和自动化的工作量，以及联调时需要涉及到与外部团队协作的工作量等等。

    开发小伙伴们会对这些工作量评估一个故事点。与产品经理一起把一系列的工作项打包安排进这个Sprint里，目的是保证团队在2个星期里能够有足够的工作可以做。

    这里大家经常采用一个假设，团队的能力capacity应该对应一个Sprint中，能完成的故事点数量。如果一个团队说，他们一个迭代能完成70个故事点，那么作为产品经理，如果我往这个迭代里排进了80个故事点或者100个故事点，那么我就能保证研发团队没有划水了！完美！我们可以开始迭代了。

    澄清一下，这种基于故事点的斗争，跟scrum没有半点关系。

scrum guide里面关于Sprint planning迭代计划是这么说的：

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. 

The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice.

Sprint planning中，需要把Sprint内需要做的工作呈现出来，团队协同制定一个相应的实施计划。相关专家也可以受邀请参加，提供建议。

    这句话很重要，The Product Owner ensures that attendees are prepared参与人都需要对Sprint planning里的讨论有充分的准备，这是PO的职责。曾经见过不少的团队在开迭代计划会议之前，对讨论内容是一无所知的，导致会议讨论的过程非常冗长，甚至临时发现一些不可行的内容，导致前期准备和文档需要推倒重来。

我在问产品经理和团队的时候，经常是这样的：

“事前有跟大家沟通过会议里要讨论的PBI么？”

“有啊，当然有。”

“是怎么样的方式呢？”

产品经理说：“我把文档邮件发给了团队。”

“哦，然后呢？”

开发团队说：“嗯，我们看了一眼标题，内容没来得及看。反正会上要解释。”