Sprint计划的输入有：

• 为Sprint准备高质量的产品Backlog；
• 团队的历史速率；
• 团队做SprintBacklog的可用时间；
• 产品负责人提议的Sprint目标。
  

Sprint计划的输出有：

• 团队承诺的Sprint目标；
• SprintBacklog。
  

Sprint计划的参与人有：

• 产品负责人；
• 团队成员；
• ScrumMaster。
  

Sprint计划的流程如图6-7所示。

图6-7Sprint计划的流程

高质量的输入是举行高效的Sprint计划会议的前提条件。

输入1：高质量的产品Backlog

Tommy团队的产品负责人是David，他经常在每个Sprint计划会议开始后飞奔而来，手里捏着几个用户故事卡片。到会场后，David气喘呼呼地给团队讲用户故事。每个用户故事都让团队成员感到头大，因为每个用户故事听起来都很大，需求也很模糊。当团队问起每个用户故事的细节时，David一样感到头大，因为他完全没有想过细节，只是在会前花了10分钟匆匆忙忙地把想法用卡片写下来了。团队问起这个Sprint的目标，David说的目标让团队集体“晕倒”，因为那个目标大到至少三个月才能实现。

可见，一份高质量的产品Backlog对Sprint计划是多么重要。很多团队为了解决这个问题梳理了“就绪的定义”（DefinitionofReady，简称DoR），定义了进入Sprint计划的前提条件。这个“就绪的定义”与“完成的定义”的作用类似，都是对用户故事的检查。两者的区别是：“完成的定义”定义了产品增量做到什么程度算是完成，而“就绪的定义”定义了产品Backlog可以进入Sprint计划的前提条件。

Tommy引导团队制定了“就绪的定义”：

• 已经打印或手写了用户故事；
• 用户故事已经具备技术可行性；
• 用户故事满足INVEST原则（好的用户故事需要遵循的原则，详见第8章）；
• 用户故事的优先级已经排好；
• 用户故事已经具备参考的文档并被团队熟悉；
• 用户故事卡片里含有对接受条件（AcceptanceCriteria）的描述；
• 已经明确了依赖关系；
• 已经估算了用户故事点数，且大小在一个Sprint完成。
  
  

与“完成的定义”一样，每个团队需要依据自己的情况来定义“就绪的定义”。对于Tommy的团队来说，如果团队与产品负责人达成了“就绪的定义”这个规约，就可以约束产品负责人David的行为，督促他维护高质量的产品Backlog，从而给团队高质量的输入。

输入2：团队的速率

下面这个案例在很多公司里都出现过。

我刚进入Tommy的团队做教练的时候，Tommy说，他们团队已经做Scrum几个月了，感觉基本的知识都会了。我说：“那很好啊，那么你们的速率是多少呢？”Tommy一脸茫然：“速率是啥？”

我问团队：“你们不知道速率是什么，那你们每个Sprint依据什么来决定要完成的工作量呢？”

团队答：“就按照产品负责人给我们的SprintBacklog来做。”我问团队：“那么你们每个Sprint的完成情况如何呢？”

团队答：“没注意过，好像都没有完成过啊！”

速率在Sprint结束时由实际完成的所有用户故事点数之和来度量。速率的统计有两个作用。

• 让团队对每个Sprint的产出量做到心里有数，这样能够做出靠谱的预测。
• 速率是发布计划的重要输入。比如，你的产品当前版本的Backlog有150个故事点，而团队每个Sprint的平均速率是30个故事点，这样你就可以预测出这个版本大概需要5个Sprint来完成。
  
  

很多团队将没有完成的用户故事也统计在速率内。这是错误的统计方法。

一个用户故事要么是完成了，要么是没完成。即使是完成了99%，也是没有完成，没完成的用户故事没有价值，因此不该统计在速率里。

Tommy团队在一个Sprint结束后，出现了这样的速率统计结果（如图6-8所示）。  

图6-8速率的计算

团队质疑道：“最后那个故事卡，差一点就完成了，为什么速率统计不是2×90%，而是0？这样没有真实统计我们团队的速率啊！”

其实，即使团队完成了用户故事的90%，但是如果没有达到“完成的定义”，就不具备完成的条件，在速率的计算中，99.9%=0。

累积了多个Sprint后，就可以计算历史Sprint的平均值，以及最大值和最小值，并将其作为下一个Sprint的参考（如图6-9所示）。

图6-9历史速率统计

图6-9的历史速率统计为团队做Sprint计划提供了量化参考，团队应依据此数据把握Sprint的装载量——在最大值和最小值之间，接近平均值。

输入3：团队做SprintBacklog的可用时间

Tommy的团队在一个Sprint计划的时候出现了这样的情况：公司要求所有工程师在这个Sprint都参加计算机编程考试，考不过的同事会影响其职位晋升。为了考过，每个人得花点时间准备一下才行。于是团队疑惑，这个Sprint还能装载多少工作呢？

如果团队有6个人，Sprint长度为10天，每天按照8小时计算，那么经计算得出，该团队成员总共的工作时间是480小时。

对于已知的干扰事件，比如，每个人都要参加考试，在这个时间里团队没有做SprintBacklog的工作，因此需要去除掉。如果每个人考试需要3小时，准备考试需要大约半天的时间，于是，基本上一天的时间就被耗进去了。因此，这个Sprint的有效长度其实只有9天。

值得注意的是，每个人有效的工作时间并不是8小时，通常也就是5~6个小时。如果用6小时来算作有效工作时间，那么经计算得出，在这个Sprint中，该团队的有效工作时间是324小时。

再看看这个Sprint里有没有人休假呢？小王休假2天，小李休半天，这样，团队的2.5天就需要被去除掉。经计算得出，可用的有效工作时间是309小时。最后，这个Sprint本身还有Scrum的基本活动：Sprint计划4小时，Sprint评审2小时，Sprint回顾2小时，Backlog梳理4小时。经计算得出，该团队可用的有效工作时间是237小时。

算到这的时候，团队说：“难怪不知道时间都去哪了！好了，本来以为480小时的工作时间现在只剩下一半了，这下可以了吧？再减就做不了什么了！”

我问团队：“这237小时，你们确实都用来开发SprintBacklog吗？”团队答：“要是没有Bug的话，是的……可是我们在每个Sprint都会收到用户发现的线上Bug，以及从以前的Sprint测试中发现的Bug也会有一些遗留到下一个Sprint里，这些都要修改。”这才是真实的Scrum世界，在开发伟大特性的同时还要清扫垃圾。所谓的零缺陷在软件世界里只是个梦想。

我问团队：“那么你们每个Sprint大概花多少时间来处理这些Bug呢？解决线上Bug和遗留Bug的时间，与开发SprintBacklog所用时间的占比是多少呢？比如，是3∶7、2∶8，还是1∶9？”

团队查看了历史数据，大概是4∶6的比例。

因此，团队真正能够装载SprintBacklog的时间是142小时（237小时×60%）。

输入4：产品负责人提议的Sprint目标

产品负责人在Sprint计划会议上提议一个Sprint目标。这个Sprint目标不是产品负责人单向压给团队的，而是需要与团队协商的。最终团队与产品负责人就目标达成共识，团队承诺的Sprint目标才是最终的目标。

Sprint计划的输入有：

• 为Sprint准备高质量的产品Backlog；
• 团队的历史速率；
• 团队做SprintBacklog的可用时间；
• 产品负责人提议的Sprint目标。
  

Sprint计划的输出有：

• 团队承诺的Sprint目标；
• SprintBacklog。
  

Sprint计划的参与人有：

• 产品负责人；
• 团队成员；
• ScrumMaster。
  

Sprint计划的流程如图6-7所示。

图6-7Sprint计划的流程

高质量的输入是举行高效的Sprint计划会议的前提条件。

输入1：高质量的产品Backlog

Tommy团队的产品负责人是David，他经常在每个Sprint计划会议开始后飞奔而来，手里捏着几个用户故事卡片。到会场后，David气喘呼呼地给团队讲用户故事。每个用户故事都让团队成员感到头大，因为每个用户故事听起来都很大，需求也很模糊。当团队问起每个用户故事的细节时，David一样感到头大，因为他完全没有想过细节，只是在会前花了10分钟匆匆忙忙地把想法用卡片写下来了。团队问起这个Sprint的目标，David说的目标让团队集体“晕倒”，因为那个目标大到至少三个月才能实现。

可见，一份高质量的产品Backlog对Sprint计划是多么重要。很多团队为了解决这个问题梳理了“就绪的定义”（DefinitionofReady，简称DoR），定义了进入Sprint计划的前提条件。这个“就绪的定义”与“完成的定义”的作用类似，都是对用户故事的检查。两者的区别是：“完成的定义”定义了产品增量做到什么程度算是完成，而“就绪的定义”定义了产品Backlog可以进入Sprint计划的前提条件。

Tommy引导团队制定了“就绪的定义”：

• 已经打印或手写了用户故事；
• 用户故事已经具备技术可行性；
• 用户故事满足INVEST原则（好的用户故事需要遵循的原则，详见第8章）；
• 用户故事的优先级已经排好；
• 用户故事已经具备参考的文档并被团队熟悉；
• 用户故事卡片里含有对接受条件（AcceptanceCriteria）的描述；
• 已经明确了依赖关系；
• 已经估算了用户故事点数，且大小在一个Sprint完成。
  
  

与“完成的定义”一样，每个团队需要依据自己的情况来定义“就绪的定义”。对于Tommy的团队来说，如果团队与产品负责人达成了“就绪的定义”这个规约，就可以约束产品负责人David的行为，督促他维护高质量的产品Backlog，从而给团队高质量的输入。

输入2：团队的速率

下面这个案例在很多公司里都出现过。

我刚进入Tommy的团队做教练的时候，Tommy说，他们团队已经做Scrum几个月了，感觉基本的知识都会了。我说：“那很好啊，那么你们的速率是多少呢？”Tommy一脸茫然：“速率是啥？”

我问团队：“你们不知道速率是什么，那你们每个Sprint依据什么来决定要完成的工作量呢？”

团队答：“就按照产品负责人给我们的SprintBacklog来做。”我问团队：“那么你们每个Sprint的完成情况如何呢？”

团队答：“没注意过，好像都没有完成过啊！”

速率在Sprint结束时由实际完成的所有用户故事点数之和来度量。速率的统计有两个作用。

• 让团队对每个Sprint的产出量做到心里有数，这样能够做出靠谱的预测。
• 速率是发布计划的重要输入。比如，你的产品当前版本的Backlog有150个故事点，而团队每个Sprint的平均速率是30个故事点，这样你就可以预测出这个版本大概需要5个Sprint来完成。
  
  

很多团队将没有完成的用户故事也统计在速率内。这是错误的统计方法。

一个用户故事要么是完成了，要么是没完成。即使是完成了99%，也是没有完成，没完成的用户故事没有价值，因此不该统计在速率里。

Tommy团队在一个Sprint结束后，出现了这样的速率统计结果（如图6-8所示）。  

图6-8速率的计算

团队质疑道：“最后那个故事卡，差一点就完成了，为什么速率统计不是2×90%，而是0？这样没有真实统计我们团队的速率啊！”

其实，即使团队完成了用户故事的90%，但是如果没有达到“完成的定义”，就不具备完成的条件，在速率的计算中，99.9%=0。

累积了多个Sprint后，就可以计算历史Sprint的平均值，以及最大值和最小值，并将其作为下一个Sprint的参考（如图6-9所示）。

图6-9历史速率统计

图6-9的历史速率统计为团队做Sprint计划提供了量化参考，团队应依据此数据把握Sprint的装载量——在最大值和最小值之间，接近平均值。

输入3：团队做SprintBacklog的可用时间

Tommy的团队在一个Sprint计划的时候出现了这样的情况：公司要求所有工程师在这个Sprint都参加计算机编程考试，考不过的同事会影响其职位晋升。为了考过，每个人得花点时间准备一下才行。于是团队疑惑，这个Sprint还能装载多少工作呢？

如果团队有6个人，Sprint长度为10天，每天按照8小时计算，那么经计算得出，该团队成员总共的工作时间是480小时。

对于已知的干扰事件，比如，每个人都要参加考试，在这个时间里团队没有做SprintBacklog的工作，因此需要去除掉。如果每个人考试需要3小时，准备考试需要大约半天的时间，于是，基本上一天的时间就被耗进去了。因此，这个Sprint的有效长度其实只有9天。

值得注意的是，每个人有效的工作时间并不是8小时，通常也就是5~6个小时。如果用6小时来算作有效工作时间，那么经计算得出，在这个Sprint中，该团队的有效工作时间是324小时。

再看看这个Sprint里有没有人休假呢？小王休假2天，小李休半天，这样，团队的2.5天就需要被去除掉。经计算得出，可用的有效工作时间是309小时。最后，这个Sprint本身还有Scrum的基本活动：Sprint计划4小时，Sprint评审2小时，Sprint回顾2小时，Backlog梳理4小时。经计算得出，该团队可用的有效工作时间是237小时。

算到这的时候，团队说：“难怪不知道时间都去哪了！好了，本来以为480小时的工作时间现在只剩下一半了，这下可以了吧？再减就做不了什么了！”

我问团队：“这237小时，你们确实都用来开发SprintBacklog吗？”团队答：“要是没有Bug的话，是的……可是我们在每个Sprint都会收到用户发现的线上Bug，以及从以前的Sprint测试中发现的Bug也会有一些遗留到下一个Sprint里，这些都要修改。”这才是真实的Scrum世界，在开发伟大特性的同时还要清扫垃圾。所谓的零缺陷在软件世界里只是个梦想。

我问团队：“那么你们每个Sprint大概花多少时间来处理这些Bug呢？解决线上Bug和遗留Bug的时间，与开发SprintBacklog所用时间的占比是多少呢？比如，是3∶7、2∶8，还是1∶9？”

团队查看了历史数据，大概是4∶6的比例。

因此，团队真正能够装载SprintBacklog的时间是142小时（237小时×60%）。

输入4：产品负责人提议的Sprint目标

产品负责人在Sprint计划会议上提议一个Sprint目标。这个Sprint目标不是产品负责人单向压给团队的，而是需要与团队协商的。最终团队与产品负责人就目标达成共识，团队承诺的Sprint目标才是最终的目标。