Sprint计划会议概要

Sprint计划会议在每一Sprint的启动阶段进行。

在Sprint计划会议的第一部分，产品所有者和Scrum开发团队（在ScrumMaster的协助下）共同审评Product Backlog，泰伦Backlog中各项目的目标和背景，并提供Scrum开发团队深入了解产品所有者想法的机会。

在会议的第二部分，Scrum开发团队从Product Backlog中挑选项目并承诺在Sprint的末期完成任务，从Product Backlog的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序以此工作。这是Scrum的重要实践之一；开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，只指导开发团队负责的项目是由Product Backlog中按顺序从上至下进行的。

开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。

Sprint计划会议通常会持续几个小时－开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完成Sprint相关工作的时间开始－换句话说，是团队成员平均的工作时间减去他们花费在检修bug和其他必要的维护工作，参加各工作日可以完成Sprint相关的工作。（图1）

Sprint周期	2星期
Sprint中包含的工作天数	8天

 

团队成员	Sprint周期中可利用的天数	每日可利用的时间	Sprint中总共可利用的时间
A	8天	4小时	32小时（8×4）
B	7天	7小时	49小时
C	6天	5小时	30小时

                                            图1预测可利用时间

当可利用时间确定下来，开发团队会从Product Backlog的顶端第一项开始工作，换句话说，从产品所有者的最高优先权项开始。团队共同工作，将其分配为小块任务，并记录在Sprint Backlog中。当任务确定后，团队成员可以资源承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估计时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务(写在便签纸上)在Sprint中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。

Scrum的重要支柱之一是当Scrum开发团队确认承诺任务后，产品所有者在此Sprint期间不可以添加新的需求。这就意味着即是在Sprint中途，产品所有者想要添加新要求，他在下一新的Sprint开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该Sprint，意味着开发团队停止一切工作，重新开始Sprint计划会议等等。此种决定会产生很大的影响，除非在非常特别情况下，否则不会采用这种方式。

保证开发团队在Sprint中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排Product Backlog中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint中不可变更的，使其在决定从哪一个项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum开发团队将会做的很好。其次，产品所有者可以在下一Sprint开始前，提出希望Product Backlog的项目变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint进行中提出任何变更，职能等待下一个Sprint。