在启动一个大项目的过程中往往需要批量估算用户故事，这是一个有挑战的过程。一方面我们不想占用太多时间，另一方面又要求具备做计划需要的准确程度（够用的准确），同时得到完整的项目范围。在众多项目中我们尝试了多种做法，来应对不同规模用户故事的估算。
大规模的估算
对于规模在200个故事以内的需求，可尝试下面2种做法：
相对估算法
旨在短时间内获取相对精确的估算
步骤：
1. 业务人员给开发团队一个个介绍故事，并Timebox讨论的时间，如每个故事不超过2分钟。
2. 比较这个故事与已分析过故事的相对大小，并放在相对大小类似的列下。左边小，右边大。意见不一致时解释一下，再决策。
3. 过完所有故事后，针对有风险的区域做整体调整。比如多个故事完成一个大需求，前面评估时不考虑实现顺序，可能放到了一起，但实际工作中先做的故事工作量会大些，因此需要针对这些故事做些调整，分散它们的相对大小。
4. 把各列故事强制分组到斐波那契数列（1,2,3,5,8,…）或倍数数列（1,2,4,8,16,...）表示的相对大小列中，考虑合并类似大小的列，或分解一列中的故事到相邻的列中。
注意事项：
1. 需要的话大家提前讨论比较相对大小时的指导，如比较技术复杂性，需求细节复杂性以及需求的不确定性等。
2. 尽可能打破大家拿点数换算成人天的固有概念。
3. 要体现群体智慧的力量，而不是某一两个人的理解，可以使用估算扑克的方法判断大小。
看看相对估算法在实际应用中的场景：
估算2.0
一种更为强调纪律性和全员强制参与的相对用户故事估算方法
步骤：
1. 准备一个较大的桌子或地面、开发人员选出顺序。待估算的用户故事放置在一边。
2. 第一位开发人员，从待估算的用户故事中选择一个认为工作量适中的用户故事卡片，放置到准备好桌子的中间部分。
3. 第二位开发人员，从待估算的用户故事中选择出一个自己熟悉的用户故事，如果比刚才选择的用户故事大，就放在刚才故事的右边。如果比刚才选择的用户故事小，就放在刚才故事的左边。相似的话就放在刚才故事的下方。
4. 第三位开发人员可以选择移动刚才第二位开发人员的卡片位置，也可以选择放置新的卡片。如果挪动位置的话要说明自己的原因。
5. 重复第4步，并循环开发人员。需求、测试人员可以提出一些疑问。
6. 所有人对故事卡片位置没有意见之后，开始放置相对估算数字。
7. 先放置1，下一个人可以选择移动1，也可以选择放置新的估算数字。
8. 可以继续调整故事卡片，最后所有人对数字没有异议，结束整个过程。
注意事项：
1. 只有开发人员可以移动卡片。
2. 测试和需求人员进行提问和解释。
3. 需要持续写出故事的假设条件。
看看估算2.0在实际应用中的场景：
更大规模的估算
如果故事规模增加到数百个，上面的做法就显得耗时太长。在一个项目中我们采用下面的做法，在一天的时间里评估了500个左右的故事和接口。
大致步骤：
1. 先将故事按照业务模块分组贴到墙上。业务模块和故事间还可以加入一层叫特性（下图中的蓝卡）。
2. 多人共同识别出工作量为1的故事（下图中贴粉条的绿卡），就是那些工作量很小的故事，做为后续评估的标准。同时标记出工作量为0，即可忽略工作量的卡（下图中贴黑条的绿卡）。
3. 多人分头识别出工作量是2的故事，也就是比1大，但不至于大3倍的故事，把数字2写到卡片上。再分头依次识别出3，5，8，...的卡。遇到难以评估的卡也标记出来（下图中贴黄条的绿卡）。
4. 针对剩下的难以评估的卡做讨论，分解，再评估。清理掉评估用的各种临时条子。
5. 计算特性的工作量，也就是特性下故事工作量的和，以便于后面利用特性做交付计划。
6. 对于后端接口（后端团队的工作单位），由一位资深工程师按照相对估算法评估。
当然，在估算活动中还有一些基本原则和细节需要牢记在心，以确保快速和够用的准确，且听下回分解。
