恭喜你终于说服团队使用相对估计的用户故事点数来估算工作量，这真的是一个非常大的进步，现在你准备好进入到你们的第一次估算扑克游戏了吗？你该怎么开始呢？哪个是1个点的故事？哪个又是3个点的呢？13个点的呢？这个游戏对你和你的团队来说都是一个全新的开始。
我曾经见过一个简单的设定初始值的方法就是先从你的产品待办列表中找出一个大家同意作为1个点的用户故事。然后，你就可以再挑选一个大概是这个用户故事2倍左右工作量的故事作为2个点的用户故事，接着就是两倍于2个点的用户故事的工作量的作为5个点的用户故事，以此类推。这样做没什么问题，但是你要清晰地意识到你的团队对这个流程还是非常陌生的，同时你又希望尽量地减少歧义和主观性。然而，任何估算本来就是主观的，因此，我在这里推荐一个更加切合实际的方法来帮助团队更好地进行估算。
一个不一样的方法
我们并不能因为我们采用了新的估算方法就把以前的估算方法看作成噩梦然后迅速忘掉。在以前的某些时候，这些方法是可行的。用例、问题、bug、功能特性——无论你管它们叫什么，团队都能够完成，而且团队也有对这些东西的工作量有一定的认识。我的方法是，我们仍然采用老式估算方法的一部份来建立起和新的用户故事点数的对应关系。下面是我的方法的流程：
1） 建立一个用户故事点数和实际时间对应的表格（为了保持表格简洁我把20，40和100点去掉了）。如下图所示：
当然，你可以根据自己的需要对时间部份进行修改。值得注意的是，随着点数的增加，在时间部分的上限和下限变得更加重要（例如不能是线性的）。这是因为越大的用户故事，包含的不确定性就越多。
2） 以团队为基础，回顾一下（可以回顾文档或者仅凭记忆）以往类似功能特性所需要的时间。需要留意的是，这里所指的时间必须包括了能够把用户故事标记成完成的所有任务的时间，例如开发、评审、设计测试、执行测试、部署等等。
3） 根据我们得到的时间，我们就使用第一步中的表格把第二步中的功能特性作为对应大小的用户故事的参考。例如，以前的XYZ特性现在成为了8个故事点数的用户故事的参考。
4） 然后我们重复这些步骤，直到我们为每个用户故事点数卡片都找到了相应的作为参考的特性为止。
有一点值得注意的是，一旦完成了这个过程以后，一定要把故事点数和时间的对应表格去掉，而使用刚刚找出来的作为参考的特性。这样，我们就可以开始把新的用户故事和作为参考的特性进行比较来进行我们的扑克游戏了。有些人会想，要么我们就继续用上面的对照表格来继续估算吧？但是，这并不是我们想要的。假如我们真的这么做的话，其实我们就是在进行套上了用户故事点数外衣的老式估算而已，而最后我们发现我们这么做纯粹是浪费时间。如果有人问起老式的估算时间方法，你就可以假装失忆然后告诉他你已经忘了，现在你唯一记得的就是要用用户故事之间进行比较，而不是直接去估算时间。唯一的例外就是团队有新成员加入的时候，而他又不熟悉估算扑克的流程，这个时候可以让他先使用故事点数和时间对应的表格进行训练一到两次。
还没结束呢
如果你按照上面的方法进行，我相信你们一定能够很容易地完成第一次估算扑克游戏，然后你们的一个Sprint马上就要开始了。但是，这还没完，仍然有一些东西需要进行调整。
在Scrum中，通常你会每天跟踪完成剩余的任务所需要的总时间（通常这会在燃尽图中反映出来）。但是，我还希望能够统计出完成的用户故事所需要的实际时间，这样，我们就可以比较实际所花的时间和之前按照1）中表格估算的差距。（嗯，也许我应该早就把那个表格给丢掉了，但实际上我总是在我的桌面上放着一份拷贝）
如果用户故事进行得很顺利，但最后发现其实这个应该是一个13个点数的用户故事，而不是8个，那么我们就应该做一些调整，把这个用户故事作为13个点数的故事的参考，这样下一次我们就能够更好地进行估算。我这么做就是为了能够让我们的估算的根基能够更牢固一些。
我会跟我的团队说明我记录实际完成的时间并不是要用于绩效考评。团队需要知道我们这么做的原因是出于“检视和应用”的考虑来改进估算而不是想要进行微观管理。
现在你已经知道要怎么做了。如果你觉得这个方法有用，或者你有更好的办法的话请告诉我。
作者:Ilan Goldstein
原文地址：http://www.scrumalliance.org/articles/368-transitioning-from-timebased-to-relative-estimation
