第一步：产品负责人陈述Sprint目标，讲用户故事

产品负责人讲解他/她提议的Sprint目标，以及他/她希望被纳入Sprint的用户故事。如果其中有些用户故事在上一个Sprint的Backlog梳理活动中已经讲解过，那么在这个步骤中可以省略，产品负责人只需要给团队明确这个Sprint要做哪些用户故事即可。

很多产品负责人不知道怎么讲用户故事。有的产品负责人把用户故事的标题念一遍，或者干脆把故事卡摊到桌上说：“就这些，你们看看有什么问题。”

产品负责人要讲清楚用户故事，需要讲以下内容。

• Who：用户是什么角色。
• What：完成什么活动。
• Why：达成什么目的。
• How：具体怎么做。如果有业务流程图、线框图、参考规范或标准等，也需要给团队介绍。
• 验收条件：做到什么程度算完成。
  

第二步：产品负责人澄清产品需求

产品负责人就Sprint目标以及每个用户故事做现场解答，确保团队每个人对用户故事都有一致的理解。在这个过程中，一般会对用户故事进行细化，有可能还会拆分出新的用户故事。

第三步：团队估算完成用户故事所需时间

在估算过程中，产品负责人会发现，有的故事貌似大家都有共同的理解，但其实没有。因此，产品负责人要对用户故事做进一步澄清，而大的故事会继续拆分，需要的话会重新估算时间。

第四步：团队选取SprintBacklog，调整Sprint目标

团队依据历史Sprint速率，以及对完成用户故事所需时间的估算，按照产品Backlog的优先级，选取用户故事，作为这个Sprint的Backlog。

依据选取的SprintBacklog，团队审视产品负责人提议的Sprint目标是否可以达成。如果SprintBacklog的范围超过了Sprint目标，团队应该与产品负责人协商，是否应该调整Sprint目标。

在Tommy团队的一个Sprint计划会议上，产品负责人David提议的Sprint目标是：用户能够完成下订单和支付的采购过程。

团队估算SprintBacklog后发现，与支付有关的用户故事没有富余时间，不能放到这个Sprint里做。于是，团队与产品负责人商议，将Sprint目标更改为：用户完成下单过程，支持货到付款，下个Sprint再做支付的流程。

第五步：拆分任务

接下来，团队就每一个用户故事拆分出具休的任务。每个任务的粒度争取在一天之内。

Tommy的团队在这个Sprint计划中有这样一个用户故事：购物者想把一个商品加到 里。

团队讨论，为了完成这个用户故事，需要完成以下任务。

• 修改后台数据库，预计5小时。
• 添加 UX设计，预计2小时。
• 前台页面JS开发，预计4小时。
• 写自动化验收测试脚本，预计3小时。
• 更新购物者帮助说明，预计2小时。
  

团队用卡片将每个用户故事和任务写下来，为方便互动，大家围着卡片讨论。卡片展开后如图6-10所示。

图6-10Sprint计划任务拆分示例图

新的Scrum团队一开始拆分出的任务通常都比较大，比如10天、8天、5天的任务。而任务最好在一天之内完成，因为任务越大，其中蕴藏的风险可能越多。团队在探讨如何把任务拆小的过程中，会 出实现用户故事的风险。

当团队形成将任务拆小的习惯后，又容易走向另一个极端：经常出现1小时或半小时的任务。比如，开发弹出消息对话框需要0.5小时。

如果有一堆过小粒度的任务，会额外增加管理成本，也是不提倡的。一天之内的粒度是最合适的。

第六步：判断SprintBacklog是否达到产能上限

Tommy团队在这个Sprint估算的任务工时之和为150小时（如图6-10所示），而在Sprint计划前的工作（输入3：团队做SprintBacklog的可用时间）中，团队做SprintBacklog的可用时间只有142小时，Tommy问大家：“这可怎么办呢？”

团队说：“才超出了8个小时，没准能做完。”

这个时候，作为ScrumMaster的Tommy问道：“大家确定可以吗？真的愿意挑战一下吗？为什么觉得可以做完呢？”

不管团队是否愿意挑战，我们应该尊重团队的决定。如果团队不想挑战，那么需要从Backlog里取下一个或几个用户故事。

第七步：承诺目标

终于到了最后一步。在Sprint计划结束前，ScrumMaster需要问大家对这个Sprint是否有信心，从而确保每个成员为达成Sprint目标做出承诺。

很多团队都省略了承诺目标这一步，ScrumMaster也没有确认大家的信心和承诺就结束了Sprint计划会议，团队直接进入开发。从大部分工程师的习惯来看，即使有人没有信心也不会说的，因为这会显得整个团队好像就他一个人没有信心。而往往他看到的风险可能是其他人没有想到的。

一种高效征求意见的方法是用五指拳（FistofFive）投票，如图6-11所示。

图6-11五指拳投

五指拳投票法的具体含义如下。

• 5个手指：完全有信心，闭着眼睛都可以达到！
• 4个手指：有信心，不出意外的话可以达到！
• 3个手指：有点信心，但需要努力！
• 2个手指：没有信心，很难达到！
• 1个手指：不可能实现，我宁愿回家睡觉！
  

如果团队有人举了2根或1根手指，ScrumMaster需要请他/她讲述自己的顾虑，困难在哪里。如果团队认可他/她提出的困难会影响Sprint目标的达成，则应该调整Sprint目标。

Sprint计划结束的时候，不仅团队承诺了Sprint目标，而且SprintBacklog也得到了团队的承诺。团队可以将SprintBacklog的用户故事和拆分的任务卡放到任务板上，作为Sprint第一天启动的站会输入。

第一步：产品负责人陈述Sprint目标，讲用户故事

产品负责人讲解他/她提议的Sprint目标，以及他/她希望被纳入Sprint的用户故事。如果其中有些用户故事在上一个Sprint的Backlog梳理活动中已经讲解过，那么在这个步骤中可以省略，产品负责人只需要给团队明确这个Sprint要做哪些用户故事即可。

很多产品负责人不知道怎么讲用户故事。有的产品负责人把用户故事的标题念一遍，或者干脆把故事卡摊到桌上说：“就这些，你们看看有什么问题。”

产品负责人要讲清楚用户故事，需要讲以下内容。

• Who：用户是什么角色。
• What：完成什么活动。
• Why：达成什么目的。
• How：具体怎么做。如果有业务流程图、线框图、参考规范或标准等，也需要给团队介绍。
• 验收条件：做到什么程度算完成。
  

第二步：产品负责人澄清产品需求

产品负责人就Sprint目标以及每个用户故事做现场解答，确保团队每个人对用户故事都有一致的理解。在这个过程中，一般会对用户故事进行细化，有可能还会拆分出新的用户故事。

第三步：团队估算完成用户故事所需时间

在估算过程中，产品负责人会发现，有的故事貌似大家都有共同的理解，但其实没有。因此，产品负责人要对用户故事做进一步澄清，而大的故事会继续拆分，需要的话会重新估算时间。

第四步：团队选取SprintBacklog，调整Sprint目标

团队依据历史Sprint速率，以及对完成用户故事所需时间的估算，按照产品Backlog的优先级，选取用户故事，作为这个Sprint的Backlog。

依据选取的SprintBacklog，团队审视产品负责人提议的Sprint目标是否可以达成。如果SprintBacklog的范围超过了Sprint目标，团队应该与产品负责人协商，是否应该调整Sprint目标。

在Tommy团队的一个Sprint计划会议上，产品负责人David提议的Sprint目标是：用户能够完成下订单和支付的采购过程。

团队估算SprintBacklog后发现，与支付有关的用户故事没有富余时间，不能放到这个Sprint里做。于是，团队与产品负责人商议，将Sprint目标更改为：用户完成下单过程，支持货到付款，下个Sprint再做支付的流程。

第五步：拆分任务

接下来，团队就每一个用户故事拆分出具休的任务。每个任务的粒度争取在一天之内。

Tommy的团队在这个Sprint计划中有这样一个用户故事：购物者想把一个商品加到 里。

团队讨论，为了完成这个用户故事，需要完成以下任务。

• 修改后台数据库，预计5小时。
• 添加 UX设计，预计2小时。
• 前台页面JS开发，预计4小时。
• 写自动化验收测试脚本，预计3小时。
• 更新购物者帮助说明，预计2小时。
  

团队用卡片将每个用户故事和任务写下来，为方便互动，大家围着卡片讨论。卡片展开后如图6-10所示。

图6-10Sprint计划任务拆分示例图

新的Scrum团队一开始拆分出的任务通常都比较大，比如10天、8天、5天的任务。而任务最好在一天之内完成，因为任务越大，其中蕴藏的风险可能越多。团队在探讨如何把任务拆小的过程中，会 出实现用户故事的风险。

当团队形成将任务拆小的习惯后，又容易走向另一个极端：经常出现1小时或半小时的任务。比如，开发弹出消息对话框需要0.5小时。

如果有一堆过小粒度的任务，会额外增加管理成本，也是不提倡的。一天之内的粒度是最合适的。

第六步：判断SprintBacklog是否达到产能上限

Tommy团队在这个Sprint估算的任务工时之和为150小时（如图6-10所示），而在Sprint计划前的工作（输入3：团队做SprintBacklog的可用时间）中，团队做SprintBacklog的可用时间只有142小时，Tommy问大家：“这可怎么办呢？”

团队说：“才超出了8个小时，没准能做完。”

这个时候，作为ScrumMaster的Tommy问道：“大家确定可以吗？真的愿意挑战一下吗？为什么觉得可以做完呢？”

不管团队是否愿意挑战，我们应该尊重团队的决定。如果团队不想挑战，那么需要从Backlog里取下一个或几个用户故事。

第七步：承诺目标

终于到了最后一步。在Sprint计划结束前，ScrumMaster需要问大家对这个Sprint是否有信心，从而确保每个成员为达成Sprint目标做出承诺。

很多团队都省略了承诺目标这一步，ScrumMaster也没有确认大家的信心和承诺就结束了Sprint计划会议，团队直接进入开发。从大部分工程师的习惯来看，即使有人没有信心也不会说的，因为这会显得整个团队好像就他一个人没有信心。而往往他看到的风险可能是其他人没有想到的。

一种高效征求意见的方法是用五指拳（FistofFive）投票，如图6-11所示。

图6-11五指拳投

五指拳投票法的具体含义如下。

• 5个手指：完全有信心，闭着眼睛都可以达到！
• 4个手指：有信心，不出意外的话可以达到！
• 3个手指：有点信心，但需要努力！
• 2个手指：没有信心，很难达到！
• 1个手指：不可能实现，我宁愿回家睡觉！
  

如果团队有人举了2根或1根手指，ScrumMaster需要请他/她讲述自己的顾虑，困难在哪里。如果团队认可他/她提出的困难会影响Sprint目标的达成，则应该调整Sprint目标。

Sprint计划结束的时候，不仅团队承诺了Sprint目标，而且SprintBacklog也得到了团队的承诺。团队可以将SprintBacklog的用户故事和拆分的任务卡放到任务板上，作为Sprint第一天启动的站会输入。