今天是第一个Sprint计划日，早上10点，所有的人都准时来到了会议室。
“好了，大家都知道今天我们要干什么。” 我开始了会议，“请每个人拿一副估算扑克。”
每个人都从我手里拿了一幅扑克，开始在手里把玩，一个个好像都是Show Hand高手。
“请Product Owner先把她希望在这次Sprint中开发的用户故事说明一下。” 我按照会议的流程开始了第一项内容。
Product Owner接上投影仪，打开Excel，列出了按照重要程度排好序的用户故事，将每个故事需要开发的内容大致介绍了一下。其间不停的有人提出一些疑问，请Product Owner解答。经过大约45分钟的讨论，大家对这些用户故事已经比较清楚了。
“现在我们开始进行估算，就像我们评估发布计划时做的一样，从第一个故事开始，每个人根据自己的估计，给出点数，但直到我允许，才翻出来给大家看。” 我开始进入第二个阶段，估算用户故事的点数以便确定Sprint Backlog。
由于是第一个Sprint，大家对于每个Sprint可以完成多少点的故事没有任何概念，所以我们决定每次估算完一个故事后，大家就开始进行任务分解，并对每个任务需要的工作时间进行估计，累计所有任务的工作时间，看看是否达到了所有团队成员在这个Sprint中可以投入的工作时间总和。也就是说，如果一个用户故事的任务分解后，总共需要50个小时，而一个5人的开发团队在两周（10天）的Sprint中总共的可用工作时间是5×10×6=300小时，（注意，这里每天的工作时间是按照6个小时计算的，而不是8个小时，这样是考虑到每天8小时的工作时间，总是有些时间需要用来参加一些与项目无关的活动，比如会议，回邮件，培训，休息等等），那么团队就可以决定这个故事可以在这个Sprint中完成，然后进行第二个故事的故事分解，看看剩下的时间是否足够可以完成第二个故事，这样反复进行，知道团队觉得已经不能承诺更多的故事为止，这时候就可以得到这个Sprint中，团队可以承诺的故事集合，也就是Sprint Backlog。
按照这个方法，我首先请大家把在这个Sprint中各自可以投入的时间汇总一下（这个团队为了确保计划会议和Demo会议的时间能够比较固定，决定总是在周一开始计划会议，而在第二周的周五进行Demo，这样实际上只有8天的工作时间）。一个开发人员说他只能有50%的时间放在这个项目上，而其他的人可以100%投入，由于总共只有3个人会参与到开发中，所以总共的时间是2.5×8×6=120小时。
有了这个时间后，我们正式开始估算，大家首先给出了第一个故事的点数，5点，然后我让团队一起立刻开始对第一个故事进行任务的分解，这个过程中，DEV和QA是各自完成任务分解，然后再汇总，得出总的需要时间，其间，QA和DEV会互相交流，以便确保对用户故事的理解是一样的，特别是QA，对于如何进行测试提出了很多的问题，这帮助大家对这个用户故事有了进一步的理解。
就在大家进行任务分解的时候，突然DEV有人叫了出来：“这个用户故事好像太大了，一个Sprint根本不可能完成。”
我看了看大家，似乎团队都有同感，于是我问他：“你能不能具体解释一下？”
“这个故事要求可以对系统的信息进行维护，可是这个涉及到增加几张数据表保存系统的信息，同时还要实现好几个API和一些UI，对信息进行增删改查的操作，同时还要对错误的操作进行处理，这太多了，无法在两周内完成。”
我转头问Product Owner：“你的意见呢？”
“嗯，如果这太复杂了，那么我可以第一步只希望有一个地方看到所有系统的信息，以方便系统管理员查看系统的状态。错误的处理可以暂时不考虑。” Product Owner说。
“那么关于其它的维护操作，你会用新的用户故事来描述，就是说，你会根据操作，进一步分割这个用户故事，是吗？” 我问到。
“是的。”
“那我们可不可以先把这个用户故事描述的再清楚一些，说明只需要查看系统的信息？”
“当然可以，我现在就改掉它。”
然后我问团队：“你们现在还觉得这个故事是5点吗？” 大家点点头，都表示同意。
团队开始继续分解任务，经过大约1个多小时的时间，他们给出了答案，第一个故事大约5点，总共需要差不多114个小时，基本上已经占满了这个Sprint的所有工作时间。考虑到第一个Sprint中，还需要一些时间来建立代码的分支版本，还有测试环境等，所以团队决定第一个Sprint只承诺一个故事。我看看Product Owner，她看上去有些失望，于是我问她：“你同意大家的决定吗？”
她犹豫了一下，然后说：“我觉得如果按照这样的进度的话，我们不可能在计划的时间内完成这个项目的。”
我对她说：“这只是刚刚开始，大家需要一些时间来熟悉这个项目，一般来说，他们的速度会随着项目的进行而提高。所以现在还不是下结论的时候。另外，之前的计划只是一个非常粗略的估计，并没有这个开发团队任何实际的数据的支持，非常有可能原来的计划并不正确。重要的是，我们现在就意识到原来的计划可能需要调整，这样我们可以有足够的时间去处理这些变化，是吗？”
“嗯，我想这一点确实是非常重要的一点，我想我们可以先这样开始，看情况再定。” Product Owner说道。
“OK，” 我对所有参加会议的人宣布说：“这个Sprint我们将实现第一个用户故事，5点，下周五Demo。会议结束，非常感谢大家”
关于作者
李丁山(Mike Li)
CSM,CSP
1998 ~ 2004 上海宝信软件 项目经理
2005 ~ 2007 Infosys中国 高级项目经理
2008 ~ 至今 Autodesk中国 项目经理
从事项目管理的相关工作近10年，期间积累比较丰富的项目管理和团队建设的经验。从2008年开始接触敏捷开发，从此成为敏捷的积极推介者。对敏捷的核心价值有较深刻的理解，同时对国内软件企业的问题有比较深刻的认识，对于敏捷的实施，注重循序渐进，与实际情况相结合，强调价值的实现而不过于拘泥于具体的方式方法。
