然后开始考虑其他用户故事。比如，对于“取出钱箱里的钱”这个故事，我们认为它跟“输入管理密码”这个故事一样简单，所以它应该也是算1个故事点。我们在列表里面标上。当然，实际操作的时候，我们是在“取出钱箱里的钱”的故事卡上填上故事点。
用户故事 故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“取消购买”，我们认为它应该是“取出钱箱里的钱”的两倍的工作量，所以它算2个故事点。
用户故事 故事点
卖饮料
取消购买 2
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“卖饮料”，我们认为它应该是“取消购买”两倍的复杂度，所以它应该算4个故事点。
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“补充饮料”，我们又认为它比“取出钱箱里的钱”复杂，但又比“卖饮料”简单，然后它又应该比“取消购买（２个故事点）”复杂，所以我们认为它应该是3个故事点：
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报
打印月销售报表
类似的，我们认为“安全警报”应该比“补充饮料”简单一些，所以应该是2个故事点：
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售报表
“打印月销售报表”应该跟“卖饮料”一样复杂，所以应该是算4个故事点，这样的话，我们总共有17个故事点：
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售报表 4
总计 17
现在挑出任意一个用户故事，估计一下它要花（你一个人）多少时间来完成。假设我们之前做过跟“取出钱箱里的钱”类似的功能，所以我们就挑这个来计算，估计它要花5天的时间。也就是说，一个故事点要花5天的时间来完成。现在我们有17个故事点，也就是说，我们需要17×5＝85天来完成这个项目（如果只是一个开发人员来做的话）。假设现在我们的团队里面有两个开发人员，所以我们就需要85÷2＝43天来完成。
从目前的估计来看，我们可以在50天的期限里面做完这个项目。但现在说这个还太早了！这样的评估，更多的是猜测。通常开发人员在工作量上的估算都很差。事实上，人们经常会低估了工作量。那我们应该怎么估计得更准？
开发速率
为了做到更准的估计，我们就让客户先给我们两周的时间做一些实际的开发，来测量一下我们在这两周里面可以做多少的用户故事。我们叫这两周的时间为“迭代周期”。
哪些用户故事应该放在第一个迭代周期里面做？这可能完全是客户决定的，也可能是大家讨论以后决定的。不过挑出的这些用户故事的故事点不应该超过这两周的承受能力。因为一个迭代周期有10天（假设我们周末不工作），然后我们估计一个开发人员5天可以完成一个故事点。现在我们有两个开发人员，所以我们应该可以在这个迭代周期中完成（10÷5）×2＝4个故事点。
然后客户可以在总故事点不超过４的前提下，挑出一些用户故事在这个迭代周期里实现。他们可能会尽量挑选他们觉得最重要的故事。比如，对他们来说，销售报表跟找零钱最重要，所以他们就挑出这两个：
用户故事 故事点
取出钱箱里的钱 1
打印月销售报表 2
总计 3
假设两周的迭代周期过去了，我们完成了“取出钱箱里的钱”，不过“打印月销售报表”没有完成，还剩0.5个故事点没有完成。也就是说，我们在这个迭代周期内完成了3-0.5＝2.5个故事点（比原来的预计要差一些）。
2.5个故事点这样的数值，就是我们现在的参考值。也就是说，这个团队每个迭代周期可以完成2.5个故事点。这个参考值对我们很有用。它有两个用处：
首先，我们可以假定我们在下个迭代周期也可以完成2.5个故事点，然后客户选择的用户故事的故事点总和不能超过2.5。
其次，在从第一个迭代周期取得参考值以后，我们可以重新估算我们的发布时间了。本来我们估算我们每个开发人员完成1个故事点的时间是5天，现在我们有了实践后的数据了，我们的团队（两个开发人员）可以在一个迭代周期（10天）内完成2.5个故事点。现在总的故事点是17，计算一下，我们需要17÷2.5＝7个迭代周期来完成。14周，也就是70天。也就是说，我们满足不了客户提出的期限（50天内）！怎么办？
不能如期完成时
很明显，现在我们完成不了全部的用户故事。在这50天里面，我们只能完成50÷10×2.5＝12.5个用户故事。因为现在有17个故事点，我们应该让客户挑出总计4.5个故事点的用户故事，推迟到下一个发布周期去。客户应该选择那些比较次要的用户故事。比如，客户可以推迟“打印月销售报表”这个用户故事。
（…….待续）
