Sprint Planning Meeting——Scrum计划会议是每个Sprint(冲刺)开始之前的一次计划会议。计划会议的目标是从Product Backlog(产品待办列表)中挑选任务至Sprint Backlog(冲刺待办列表)，决定下一个Sprint要交付的内容。
本文是Scrum敏捷开发那些会议的第二篇，将会介绍Sprint计划会议的方方面面。
时间、地点、人物
Timebox
上文已经提到，Sprint计划会议会在每个Sprint开始之前召开。除了这个固定的时间，还有一个很重要的时间概念——Timebox(限制的时间段)。Scrum的每个流程及会议都拥有一个相对固定的限制时间，一般来说，计划会议持续时间尽量控制在1-3小时。
限制时间可以提高会议的效率，也可以防止会议过多地占用工作时间或打乱工作节奏。如何保持工作的节奏感：相对固定的Sprint周期+相对固定的会议时间（例如：每个Sprint开始周的周二召开计划会议）
地点
与站会不同，计划会议需要长时间的讨论，选择在会议室召开较为合适。
与会人员
Scrum Master, Product Owner, Scrum Team都需要参加计划会议。Scrum Master负责会议的顺利进行，Product Owner负责澄清Product Backlog中的待办项目的细节，Scrum Team则根据需求做出下个Sprint的承诺。
事件
确定了时间、地点和人物，接下来要解决的就是计划会议的具体内容了。
到底如何将Product Backlog中任务移动至Sprint Backlog。
第一步是明确下一个Sprint的交付范围。
Scrum中每个Sprint都需要交付可工作的软件，每一个Sprint都会将一些增量加入其中。这个增量就是Sprint Goal(目标)。
决定交付范围要同时考虑任务优先级以及Scrum Team的生产力，这个决定是产生自Scrum Team，Product Owner只做引导性的工作。
在这个过程中，Scrum Team将Product Backlog中的item挪动至Sprint Backlog, 但只是挪动而已，接下来还有别工作要做。在大致明确了交付范围之后，Scrum Team需要对所有的item进行必要的细化，对任务进行拆分，尽量保证每一个item都可以在2个工作日内完成。在拆分任务的同时，与Product Owner确认DoD(Definition of Done)，即完成的定义。
DoD对于敏捷来说是非常关键的检查点，这是Team做出的承诺中最核心的部分
接下来的工作就是Estimation——预估。在确认最终的Sprint Backlog前，Scrum Team要保证他们可以给出一个可被接受的承诺，这个承诺通常有两个含义：第一，下一个Sprint，Team可以交付有效的并含有增量工作软件；第二，Team可以在Sprint结束前按时交付。
Scrum Team可以根据斐波那契数列估算User Story points，或是通过小时数来表明每个item的工作量。将最终估计的结果与以往的实际情况相比较，来确定Team是否能够承受，并适当做出调整。最后在承诺之前，再对Sprint Backlog做一次审阅：
- 确认所有的item都有DoD和Estimation
- 确保没有遗漏互相依赖的item
- 确认提供的增量可以被接受
- 确认所有相关人都已经了解Sprint Backlog的内容
Sprint开始后，任何人都不可以也不应该将额外的item加入Sprint Backlog，不仅因为这会打乱Srum Team的节奏，也违反了承诺的原则
实践出真知
最后来谈一谈持续改进。每一个Team，都是由陌生到熟悉，由生疏到成熟，相对来说越成熟的Team就越高效。
对于计划会议来说，Estimation的精准度很重要，因为它意味着Scrum Team能否做出对自己以及对任务的准确评估，或者说能否做出一个有效的承诺。持续改进的过程，也是一个不断记录和对比过去的过程，通过数据对比，Scrum Team可以更清楚地了解自己的能力。
Velocity chart, 对比承诺的工作量和实际的工作量的图表，反应出Team实际的工作能力以及在项目演进过程中的进步或是瓶颈。
