《硝烟中的Scrum和XP》第4章 我们怎样制定sprint计划

第4章 我们怎样制定sprint计划

• sprint计划会议非常关键，应该算是Scrum中最重要的活动。只是它执行得不好，整个sprint甚至都会被毁掉
• 举办sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心
• sprint计划会议会产生一些实实在在的成果

1. sprint目标
2. 团队成员名单（以及他们的投入程度，如果不是100%的话）
3. sprint backlog（即sprint中包括的故事列表）
4. 确定好sprint演示日期
5. 确定每日scrum会议的时间和地点

为什么产品负责人必须参加

• 有时候产品负责人会不太情愿跟团队一起花上几个小时制定sprint计划。“嘿，小伙子们，我想要的东西已经列举出来了，我没时间参加你们的计划会议。”这可是个非常严重的问题
• 为什么整个团队和产品负责人都必须要参加sprint计划会议？原因在于，每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖
• 范围（scope）和重要性（importantce）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化

• 会议启动以后，产品负责人一般会先概括一下希望在这个sprint中达成的目标，还有他认为最重要的故事。接下来，团队从最重要的故事开始逐一讨论每个故事，一一估算时间。在这个过程中，他们会针对范围提出些重要问题：“删除用户这个故事，需不需要遍历这个用户所有尚未执行的事务，把它们统统取消？”有时答复会让他们感到惊讶，促使他们调整估算
• 在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法不太一样。这可能会让调整故事的重要性；或者修改故事的范围，导致团队重新估算，然后一连串诸如此类的连锁反应。
• 这种直接的协作形式是Scrum的基础，也是所有敏捷软件开发的基础。
• 如果产品负责人还是坚持没时间参加怎么办？一般我会按顺序尝试下面的策略

1. 试着让产品负责人理解，为什么他的直接参与事关项目成败，希望他可以改变想法
2. 试着在团队中找到某个人，让他在会议中充当产品负责人的代表。告诉产品负责人，“既然你没法来开会，我们这次会让Jeff代表你参加。他会替你在会议中行使权利，改变故事的优先级的范围。我建议，你最好在会议开始前尽可能跟他沟通到位。如果你不喜欢Jeff当代表 ，也可以推荐其他人，只要他能全程参加我们的会议就行”
3. 试着说服管理团队为我们安排新的产品负责人
4. 推迟sprint的启动日期，直到产品负责人找到时间参会为止。同时拒绝承诺任何交付。让团队每天都可以自由做他们最想做的事情

为什么不能在质量上让步

• 我尽力把内部质量和外部质量分开

1. 外部质量：系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣
2. 内部质量：用户看不到的要素，它们对系统的可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等

• 一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样
• 我把外部质量也看作范围的一部分。有时出于业务考虑，可能会先发布一个系统版本，其用户界面给人的感觉可能比较简陋，而且反应也很慢；不过随后会发布一个干净的版本。我都是让产品负责人做权衡，因为他是负责定义项目范围的人
• 假设产品负责人这样说，“好吧，你们把它估算成6个故事点也行。但我相信：一定能够找到些临时方案，节省一半时间。你们只要稍稍动下脑子就行”
• 啊哈！他想把内部质量当作变量来处理。我是怎么知道的？因为他想让我们缩减故事的估算时间，但不想为缩减范围“买单”。“临时方案”这个词应当在你脑中敲响警钟……
• 经验告诉我：牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了
• 碰到这种情况，我就会试着把话题转回到范围上来。“既然你想尽早得到这个特性，那我们能不能简化错误处理的功能，把“高级错误处理”当作一个单独的故事，放到以后再实现。或者也可以降低其他故事的优先级，好让我们集中处理这一个”
• 一旦产品负责人弄清楚内部质量是不可能让步的，他一般都会处理好其他变量

无何止的sprint计划会议

• 在sprint计划会议中最困难的事情是

1. 人们认为他们花不了多长时间
2. ……但他们会的！

• 假如sprint计划会议接近尾声，但仍然没有得出sprint目标或者sprint backlog，这时该怎么办？我们要打断它么？还是再延长一个小时？或者到时间就结束会议，然后明天继续？
• 这种事情会一再发生，尤其是在新团队身上。你会怎么做？我不知道。但我们的做法是什么？嗯……我通常会直接打断会议，中止它，让这个sprint给大家点儿罪受吧。具体一点，我会告诉团队和产品负责人：“这个会议要在10分钟以后结束。我们到目前为止还没有一个真正的sprint计划。是按照已经得出的结论去执行，还是明早8点再开4小时的会？”
• 我会打断会议。是的，这个sprint让大家不太好过。但我们应该看到它的正面影响，整个团队都从中获益匪浅，下个sprint计划会议更有效率。另外，如果他们从前还觉得你定下的会议时间过长的话，下次他们的抵制情绪就会少一些了
• 学会按照时间盒安排工作，学会制定合乎情理的时间盒，这对会议长度和sprint长度同样有帮助

sprint计划会议日程

• 在sprint计划会议之前先为它初步制定一个时间表，可以减少打破时间盒的风险
• sprint计划会议：13:00-17:00（每小时休息10分钟）
• 13：00-13：30：产品负责人对sprint目标进行总体介绍，概括产品backlog。确定演示的时间和地点
• 13：30-15：00：团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有 重要性高的backlog条目都要填写“如何演示”
• 15：00-16：00：团队选择要放入sprint中的故事。计算生产率，用作核查工作安排的基础
• 16：00-17：00：为每日scrum会议（以下简称每日例会）安排固定的时间和地点（如果和上次不同的话）。把故事进一步拆分成任务
• ScrumMaster根据会议进程的需要，可以对各个阶段的子进程时间安排进行调整

确定sprint长度

• sprint演示日期是sprint计划会议的产出物，它被确定下来以后，也就确定了sprint的长度

1. 时间短就好：公司会因此而变得“敏捷”，有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而来
2. 时间长的sprint也不错。团队可以有更多时间充分准备、解决发生的问题、继续达到sprint目标，你也不会被接二连三的计划会议、演示等等压得不堪重负

产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的sprint。所以sprint的长度是妥协后的产物。做过多次实验后，我们最终总结出了最喜欢的长度：三个星期。绝大部分团队的sprint长度都是三周

• 刚开始要试验sprint的长度的长度。不要浪费太多时间做分析。选一个可以接受的长度先开始再说，等做完一两个sprint再进行调整。
• 不过，确定了自己最喜欢的长度之后，就要在长时间内坚持不变。保持住这个长度以后，它似乎变成了大家共同的心跳节奏，每个人都感觉很舒服。这段时间内无需讨论发布日期之类的事情，因为大家都知道：每过三周都会有一个发布

确定sprint目标

• 几乎每次sprint计划会议都要确定sprint目标。在sprint计划会议进行中，我会选某个时刻问一个问题，“这个sprint的目标是什么？”每个人都目光空洞地看着我，产品负责人也皱起眉头，开始挠下巴
• 它必须用业务术语表达，而不是技术词汇，让团队以外的人也能够理解
• sprint目标应该是尚未达成的
• 可以在一个wiki页面列出所有团队的sprint目标，然后把它们放在一个显著位置上，保证公司所有人（不只是顶级管理层）知道公司在干什么，目的又是什么！

决定sprint要包含的故事

• 就是哪些故事需要从产品backlog拷贝到sprint backlog

• 每个矩形都表示一个故事，按重要性排序。最重要的故事在列表顶部。矩形尺寸表示故事大小（也就是以故事点估算的时间长短）。括号的高度表示团队估算的生产率（estimated velocity），也即团队认为他们在下一个sprint中所能完成的故事点数
• 右侧的sprint backlog是产品backlog中的一个故事快照。它表示团队在这个sprint中承诺要完成的故事
• 在sprint中包含多少故事由团队决定，而不是产品负责人或其他人
• 这引发了两个问题

1. 团队怎么决定把哪些故事放在sprint里面？
2. 产品负责人怎么影响他们的决定？

产品负责人如何对sprint放哪些故事产生影响

• 假设在sprint计划会议中我们遇到下图所示的情况

• 产品负责人很失望，因为故事D不会被放在sprint里面。首先，他可以重新设置优先级。如果他给故事D赋予最高的重要级别，团队就不得不把它先放到sprint里面来（在这里需要把C扔出去）

• 其次，他可以更改范围——缩小故事A的范围，直到团队相信故事D能在这个sprint里完成为止
• 最后，他还可以拆分故事。产品负责人判断出故事A中某些方面实际并不重要，所以他把A分成两个故事A1和A2，赋给它们不同的重要级别

团队怎样决定把哪些故事放到sprint里面

• 这里使用两个技术

1. 本能反应
2. 生产率计算

用本能反应来估算

ScrumMaster：“伙计们，我们在这个sprint里面能完成故事A吗？” Lisa：“呃。当然可以。我们有三个星期，这只是个微不足道的特性” ScrumMaster：“OK，那加上B怎么样？” Tom和Lisa一起回答：“自然没问题” ScrumMaster：“OK，那ABC一起呢？” Sam：“故事C要包括高级错误处理么？” 产品负责人：“不，你现在可以跳过它，只需要完成基本的错误处理” Sam：“那C应该没问题” ScrumMaster：“OK，那再加上D呢？” Lisa：“嗯……” Tom：“我觉得能完成” ScrumMaster：“有多少把握？90%还是50%” Lisa和Tom：“差不多90%” ScrumMaster：“OK，D也加进来。那再加上E呢？” Sam：“也许吧” ScrumMaster：“90%？50%？” Sam：“差不多50%” Lisa：“我没把握” ScrumMaster：“OK，那先把它放一边去。我们要做完ABCD。如果有时间的话，当然还可以做完E，不过既然没人指望它能完成，所以我们也不会把它算到计划里面来。现在怎么样？” 所有人：“OK”

• 如果sprint时间不长，小团队根据直觉进行估算可以收到很好的效果

用生产率计算来估计

1. 得抽估算生产率
2. 计算在不超出估算生产率的情况下可以加入多少故事

• 生产率是“已完成工作总量”的一个衡量方式，其中每一个条目都是用它的原始估算进行衡量的
• 下图中，左边是sprint启动的估算的生产率，右边是sprint结束时的实际生产率。每个矩形都是一个故事，里面的数字表示这个故事的原始估算

• 注意，这里的实际生产率建立在每个故事的原始估算基础之上。在sprint过程中对故事时间进行的修改都被忽略了
• 这个数字并不精确。但它依然很有用，尤其是与啥都没有相比，感觉就更明显了。它可以给你一些硬生生的事实：“抛开具体原因，我们曾经以为能完成这么多，而实际完成的工作与当初预计的还是有区别”
• 那个sprint里面差不多可以完成的故事怎么处理？为什么我们在实际生产率里面没把它的部分故事点数算进来？这就突出表现了Scrum的要求（实际上也是敏捷软件开发和精益制造的要求）：把事情完全做完！达到可以交付的状态！事情只做了一半，它的价值就是0（也许还会是负数）
• 我们在估算生产率的时候，动用了何等神奇的魔力？
• 有一个很简单的办法：看看团队的历史。看看他们在过去几个sprint里面的生产率是多少，然后假定在一一个sprint里面生产率差不多不变
• 这项技术也叫“昨天天气”。要想使用该技术，必须满足两个条件：团队已经完成了几个sprint（这样就可以得到统计数据），会以几乎完全相同的方式（团队长度不变，工作状态等条件不变）来进行下一个sprint
• 例如，这个sprint一共有50个可用的人天

• 这是我们的估算生产率么？不！我们估算的单位是故事点（story point），差不多可以对应于“理想化的人-天”。一个理想化的人-天是完美、高效、不受打扰的一天，但这种情况太少见了。我们还必须考虑到各种因素，例如要把未计划到的工作添加到sprint中、人们患病不能工作等等
• 我们的估算生产率肯定要比50少了。少多少呢？我们引入“投入程度”（focus factor）这个词来看一下

• 投入程度用来估算团队会在sprint中投入多少精力。投入程度低，就表示团队估计会受到很大干扰，或者他们觉得自己的时间估算太过理想化
• 要想得出一个合理的投入程度，最好的办法就是看看上一个sprint的值 （对前几个sprint取平均值 自然更好）

• 把上一个sprint中完成的所有故事的原始估算加起来，得到的和就是实际生产率

• 从上面的公式中可以看出，下个sprint的估算生产率是20个故事点。这表明团队这个sprint中所能做的故事点数之和不能超过20

• 在这种情况下，团队可以选择前4个故事，加起来一共19个故事点；或者选前5个故事，一共24个故事点。我们假设他们选了4个故事，因为它离20最近。如果不太确定，那就再少选些好了
• 因为这4个故事加起来一共19个故事点，所以他们在这个sprint中最后的估算生产率是19
• “昨天天气”用起来很方便，但需要考虑一些常识。如果上一个sprint干得很糟，是因为大部分成员都病了一星期。那你差不多可以放心假设这次运气不会那么坏，给这个sprint设个高点的投入程度；如果团队最近刚装了一个执行速度快如闪电的持续集成系统，那你也可以因此提高一下投入程度；如果有新人加入这个sprint，那就把他的培训占用的精力也算进来，降低投入程度；等等
• 只要条件允许 ，你就应该看看从前的sprint，计算出平均数，这样可以得到更合理的估算
• 如果这是个全新的团队，没有任何数据怎么办？可以参考一下类似条件下工作的团队，他们的投入程度数值是多少
• 如果没有其他团队可以参考怎么办？随便猜一个数作为投入程度吧。毕竟这个猜测只会在第一个sprint里面使用。过了这次以后你就有了历史数据可以分析，然后对投入程度和估算生产率做出不断的改进
• 我在新团队中使用的“默认”投入程度通常是70%，因为这是其他大多数团队都能达到的数值

我们用的是哪种估算技术

• 我们审视上个sprint的投入程度和实际生产率。我们审视这个sprint总共可用的资源，估算一个投入程度。我们讨论这两个投入程度之间的区别，必要时进行调整
• 大致有了一个要放入sprint的故事列表以后，我再进行“直觉反应”的检查。我要求他们暂时忘掉数字，感觉一下：在一个sprint里一口咬这么多东西会不会难以下咽。如果觉得太多了，那就移走一两个故事。反之亦基
• 当天结束以前，只要得出哪些故事要放到sprint里面，我们就算完成了目标。投入程度、资源可用性和估算生产率只是用来达成这个目标的手段

我们为何使用索引卡

• 在大多数sprint计划会议上，大家都会讨论产品backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成
• 要想收到好的效果，不妨创建一些索引卡，把它们放到墙上（或一张大桌子上）

• 这种用户体验比计算机和投影仪好得多，理由如下

1. 大家站起来四处走动=》他们可以更长时间地保持清醒，并留心会议进展
2. 他们有更多的个人参与感（而不是只有那个拿着键盘的家伙才有）
3. 多个故事可以同时编辑
4. 重新划分优先级变得易如反掌——挪动索引卡就行
5. 会议结束后，索引卡可以拿出会议室，贴在墙上的任务板上

• 可以手写索引卡，也可以用简单的脚本从产品backlog中直接生成可以打印的索引卡（我博客上有这种脚本，地址是blog.crisp.se/henrikkniberg）
• 重要事项：sprint计划会议结束后，我们的ScrumMaster会手工更新Excel中的产品backlog，以反映故事索引卡中发生的变化。这确实给管理者带来了一点麻烦，但是考虑到用了物理索引卡以后，sprint计划会议的效率得到了大幅度提高，这种做法还是完全可以接受的
• 我们根据重要性给卡片排序（我们一般把最重要的放到左边，依次向右排列）。不过，一旦卡片被放到墙上，那就可以暂时忽略它的重要性评分，根据它们摆放的相对位置，来对比彼此的重要性。如果产品负责人交换了两张卡片，先不要浪费时间在纸上更新数字，只要确保会议结束后在产品backlog做更新就可以
• 把故事拆分成任务后，时间估算就变得更容易（也更精确）了
• 我们用即时贴贴在每个故事的下方，每张即时贴表示这个故事中的一个任务

• 我们不会让任务拆分出现在产品backlog中，原因如下

1. 任务拆分的随机性比较强，在sprint进行中，它们常常会发生变化，不断调整，所以保持产品backlog的同步很让人头大
2. 产品负责人不需要关心这种程度的细节

定义“完成”

• 有一点很重要：产品负责人和团队需要对“完成”有一致的定义。所有代码被check in以后，故事就算完成了吗？还是被部署到测试环境中，经过集成测试组的验证以后才算完成？我们尽可能 使用这样的定义：“随时可以上线”，不过有时候我们也这样说：“已经部署到测试服务器上，准备进行验收测试”
• 最开始我们用的是比较详细的检查列表。现在我们常说：“如果Scrum团队中的测试人员说可以，那这个故事就算完成了”。然后责任就到了测试人员身上，他需要保证团队理解了产品负责人的意图，要保证故事的“完成”情况可以符合大家认可的定义
• 我们慢慢意识到，不能把所有的故事都一概而论。“查询用户表单”跟“操作指南”这两个故事的处理方式就有很大差别。对后者，“完成”的定义可能就是简单的一句话——“被运营团队认可”。所以说，日常的一些认识往往要好过正式的检查列表
• 如果你常常对怎样定义完成感到困惑（就像我们刚开始一样），你或许应该在每个故事上都添加一个字段，起名为“何谓完成”

使用计划扑克做时间估算

• 估算是一项团队 活动——通常每个成员都会参与所有故事的估算。为啥要每个人都参加？

1. 在计划的时候，我们一般都还不知道到底谁会来实现哪个故事的哪个部分？
2. 每个故事一般有好几个人参与，也包括不同类型的专长（用户界面设计 、编程、测试等）
3. 团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础，也有助于故事中的重要问题被尽早发现
4. 如果要求每个人都对故事做估算，我们就会常常发现两个人对同一个故事的估算结果差异很大。我们应该尽早发现这种问题并就此进行讨论

• 有一项很优秀的技术可以避免这一点——它的名字是计划扑克。每个人都会得到如下图所示的13张纸牌。在估算故事的时候，每个人都选出一张纸牌来表示他的时间估算（以故事点的方式），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。
• 如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同
• 重要的是，我们必须提醒团队成员，他们要对这个故事中所包含的全部工作进行估算，而不是“他们自己负责”的部分工作。测试人员不能只估算测试工作

• 注意，这里的数字顺序不是线性的。例如在40和100之间就没有数字
• 因为一旦时间的估算值比较大，其精确度就很难把握；这样做就可以避免人们对估算精确度产生错误的印象。如果一个故事的估算值 是差不多20个故事点，它到底应该是20还是18还是21，其实无关紧要。我们知道的就是它是一个很大的故事，很难估算。所以20只是一个粗略估计
• 需要进行更精确的估算？那就把故事分拆，去估算那些更小的故事！
• 另外，你也不能搞那种把5和2加起来得到7的把戏。要么选5，要么选8，没有7
• 下面这些卡片比较特殊

1. 0：这个故事已经完成了或这个故事根本没啥东西，几分钟就能搞定
2. ？：我一点概念都没有。没想法
3. 咖啡杯：我太累了，先歇会吧

明确故事内容

• 在sprint演示会议上，团队自豪地演示了一个新特性，但产品负责人却皱起眉头，“呃，看上去不错 ，但这不是我要的！”发生这种事情可真是糟透了！
• 有些简单技术，可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满（更精确地说，这里提到的是具有高优先级，应该在这个sprint里面完成的故事）

例1 团队和产品负责人都对sprint计划很满意，打算结束会议。这时ScrumMaster问了一个问题，“等一下，还有个“添加用户””的故事没有估算时间呢，把它解决了吧！“几轮计划扑克以后，团队意见达成一致，认为这个故事需要20个故事点；产品负责人却站了起来，说话因为生气也走了调：”什、什、什么？！“经过几分钟的激烈争吵，最后发现是团队错误理解了”增加用户“这个故事的范围，他们以为这表示”要有个漂亮的Web界面来添加、删除、移除和查询用户“，但是产品负责人只是想”通过手写SQL操作数据库来添加用户“。他们重新进行评估，给它5个故事点，达成共识 例2 团队和产品负责人都对sprint计划很满意，打算结束会议。这时ScrumMaster问了一个问题，”等一下，还有一个'添加用户'的故事，它怎么演示呢？“一阵窃窃私语之后，某人站起来说，”呃，首先我们登录Web站点，然后……“产品负责人打断了他的话，”登录Web站点？！不不不，这个功能跟Web站点一点关系都没有，你给技术管理员提供个傻瓜都能用的SQL脚本就行“

• ”如何演示“这段描述可以（而且应该）非常精简！不然你就没法按时结束sprint计划会议。基本上，它就是最平白浅显的语言，来描述如何手工执行最典型的测试场景。”先这样，然后那样，最后验证这一点“
• 我发现，使用这种简单的描述，常常能够发现对于故事范围的最严重的误解。这种事发现得越早越好

把故事拆分成更小的故事

• 如果你有一大堆0.5个故事点的故事，那你恐怕就会成为微观管理的受害者了。与之相反，40个点的故事，到最后很可能只能部分完成，这样不会为公司带来任何价值，只会增加管理成本。如果你们估算的生产率是70，而最高优先级的两个故事都是40个故事点，那做计划可就有麻烦了
• 我发现很大的故事基本上都能进行拆分。只要确定每个小故事依然可以交付业务价值就行
• 我们常常都力求保证故事的大小在2-8个人一天之间。一个普通团队的生产率大约是40---60，所以大概每个sprint可以完成10个故事。有时会减少到5个，有时也会多到15个。处在这个数量范围之间的索引卡是比较容易管理的

把故事拆分成任务

• 故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心
• 在下图的例子中，故事被拆分成更小的故事

• 下图是把故事拆分成任务的例子

• 我们会看到一些很有趣的现象

1. 新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法
2. 有些故事，大家都理解得很清楚，预先拆分还是随后拆分都一样简单
3. 这种类型的拆分常常可以发现一些会导致时间估算增加的荼，最后得出的sprint计划会更贴近现实
4. 这种预先拆分可以给每日例会的效率带来显著提高
5. 即使拆分不够精确，而且一旦开始具体工作，事先的拆分结果也许会发生变化，但我们依然可以得到以上种种好处

• 注意——我们在实践TDD（测试驱动开发），所以几乎每个故事的第一个任务都是”编写一个失败的测试“，而最后一个任务是”重构“（提高代码的可读性，消除重复）

定下每日例会的时间地点

• 一般是9：00、9：30或者10：00.最关键的是，这必须是每个人都能完全接受的时间

最后界限在哪里

• 如果时间不够，我们应该把哪些做的事情砍掉呢？

1. sprint目标和演示日期。这是启动sprint最起码应该有的东西。团队有一个目标，一个结束日期，然后就可以马上根据产品backlog开始工作
2. 经团队认可、要添加到当前sprint中的故事列表
3. sprint中每个故事的估算值
4. sprint中每个故事的”如何演示“
5. 生产率和资源计算，用作sprint计划的现实核查。包括团队成员的名单及每个人的承诺（不然就没法计算生产率）
6. 明确每日例会固定举行的时间地点。这只需要花几分钟，但如果时间不够用，ScrumMaster可以在会后直接定下来，邮件通知所有人
7. 把故事拆分成任务。这个拆分也可以在每日例会上做，不过这会稍稍打乱sprint的流程

技术故事

• 我指的是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值

示例

1. 安装持续构建服务器：为什么要完成它？因为它会节省开发人员大量时间，到迭代结束的时候，集成也不太容易出现重大问题
2. 编写系统设计概览：为什么要完成它？因为开发人员常常会忘记系统的整体设计，写出与之不一致的代码。团队需要有个描述整体概况的文档，保证每个人对设计都有同样的理解
3. 重构DAO层：为什么要完成它？因为DAO层代码已经乱成一团了。混乱带来了本可以避免的bug，每个人的时间都在被无谓地消耗。清理代码可以节省大家的时间，提高系统的健壮性
4. 升级Jira（bug跟踪工具）：为什么要完成它？当前的版本bug狂多，又很慢，升级以后可以节省大家时间

• 实际上，出于显而易见的原因，技术故事常常会因为某种原因给设置一个低优先级，例如：”嘿，兄弟们，我知道持续构建服务器很重要，不过让我们先来完成一些可以带来收入的特性吧，然后再来弄那些技术上的东西，行不？“。产品负责人往往不能对此做出正确的权衡。我们可以采取下面这些做法

1. 试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出正确的权衡
2. 如果无法把技术故事转变成普通故事，那就看看这项工作能不能当作另一个故事中的某个任务。例如，”重构DAO层“可以作为”编辑用户“中的一个任务，因为这个故事会涉及到DAO层
3. 如果以上二者都不管用，那就把它定义为一个技术故事，用另外一个单独的列表来存放。产品负责人能看到它，但是不能编辑它。用”投入程度“和”预估生产率“这两个参数来跟产品负责人协商，从sprint里拨出一些时间来完成这些技术故事

• 下面是一个示例

团队：”我们要完成一些内部的技术工作，也许要从我们的时间里抽出来10%，也就是把投入程度从75%降低到65%，你看行吗？“ 产品负责人：”不行！我们没那个时间了！“ 团队：”嘿……那看看上一个sprint吧。（大家的头全转向了白板上的生产率草图。）我们估算的生产率是80，但实际才有40，没错吧？“ 产品负责人：”没错！所以我们没时间干那些内部的技术活了！我们需要新功能 ！“ 团队：”呃，我们的生产率变得这么糟糕的原因就是，构造可以测试的稳定版本占用了太多时间“ 产品负责人：”嗯，那然后呢？“ 团队：”唔，如果我们不做点什么的话，生产率还会继续这么烂下去“ 产品负责人：”嗯，接着说？“ 团队：”所以我们建议在这个sprinnt里抽出大概10%的时间来搭一个持续构建服务器，完成相关的一些事情，这样就 不会再受集成的折磨，接下来，每个sprint里面，我们的生产率都会提高至少20%！“ 产品负责人：”啊？真的吗？那为什么上个sprint我们没这么干？！“ 团队：”嗯……因为你不同意……“ 产品负责人：”哦，嗯……那好吧，这主意听上去不错，开始干吧！“

• 当然，还可以把产品负责人排除在外，或者是告诉他一个不可协商的投入程度。但你不妨先尝试一下，让你们的想法达成一致
• 建议你最好还是尽量让他知道所有的事情，让他制定一切工作优先级。透明也是Scrum的核心价值

bug跟踪系统vs.产品backlog

1. 产品负责人打印出Jira中优先级最高的一些条目，带到sprint计划会议中，跟其他故事一起贴到墙上（因此就暗暗地指明了这些难题相对其他故事的优先级）
2. 产品负责人创建一些指向Jira条目的故事。例如”修复那几个后台报表最严重的bug，序号是Jira-124、Jira-126……“
3. 修复bug当作sprint以外的工作，也就是说，团队会保持一个足够低的投入程度（例如50%），从而保证他们有时候来修复bug。然后我们就可以简单假设，在每一个sprint中，团队都会用一些时间来修复Jira上报告的bug
4. 把产品backlog放到Jira上（也就是放弃Excel）。把bug与其他故事同等看待

• 我还是倾向于使用第一种方案。既简单，效果又好

sprint计划会议终于结束了

• sprint计划会议是Scrum中最重要的活动。在这里投入大量努力，保证它顺利完成，后面的工作就会轻松很多
• 如果每个人（所有的团队成员和产品负责人）离开会场时都面带微笑，第二天醒来时面带微笑，在第一次的每日例会上面带微笑，那sprint计划会议就是成功的