说到敏捷估算，就不能不提到它的基本原则：使用相对的估算单位（比如：故事点），提倡详细讨论估算用户故事的内容，对解决方案形成共识并作出承诺，并通过协作增强团队凝聚力。
我身边的不少敏捷团队都会用「计划扑克」来估算故事点，不过这种方法虽然流行，却也有它的限制，比如说：待估算的功能过大，用「计划扑克」弄不好估算出 300 个故事出来；或者待估算的用户故事没有足够的信息作参照；再或者时间紧迫，来不及预估整个产品需求列表。
那么，除了「计划扑克」，还有哪些敏捷估算的方法呢？
今天我就用这篇文章来讲讲七种敏捷估算的方法：
一、计划扑克
所有参与的人都用带编号的扑克牌来估算用户故事，估算时匿名投票，如果出现较大分歧时展开讨论，然后再次投票，直到整个团队就估计的准确性达到共识。计划扑克的使用有局限性，最适合小团队（5 – 8 人）和少量用户故事（最多不超过 10 个）的估计。
小贴士：把估值控制在你们 hold 得住的范围内，不要超过十三点（一语双关）。
二、T 恤尺码
用 T 恤的尺码来估算用户故事大小：XS、S、M、L、XL。每个尺码代表多大，需要团队进行开诚布公的讨论。这个办法很简单快捷，可以粗线条地估算产品需求列表的大小。
小贴士：这种方法适合估算大型用户故事的海量需求列表，尤其是几个 Scrum 团队都围绕一个产品工作的情况。
三、点投票
这种方法适合估算小用户故事，且方法本身十分简单有效。「点投票」本是一种决策方式，但你也可以把它用在估算用户故事上。方法是：每个人分到几张便利贴，自由选择为哪些用户故事投票。一个用户故事得到的点数越多，代表着它体量越大。
小贴士：这种方法在大小团队里都可以使用，但你要去限制被估算用户故事的数量。
四、水桶体系
如果你要找一种比计划扑克效率高的估算方式，则非「水桶体系」莫属了。如果需要估算多人参与的多个用户故事时，「水桶体系」就可以发挥优势。首先，按照「计划扑克」的顺序，用棕色的纸张折几个「水桶」。然后，团队把待估算用户故事写在便利贴上，放入「水桶」估算。
小贴士：如果你打算忽略掉已经讨论过的用户故事，也可以在估算过程里使用真正的水桶。
五、三分法
「大、不确定、小」三分法是一种非常快捷的粗略估算方法，这种方法要求团队把每个用户故事都归于这三类之一。首先，把容易确定的用户故事归位到大、小两个类别下；然后，再集体讨论剩下难以归类的用户故事；最后，为这三个类别确定各自的大小。
小贴士：这个办法实际上是「水桶体系」的简化版，特别适合那些手头用户故事有可比性的小团队。
六、找相似
乍一看，你可能以为这种方法像那种「连连看」、「找茬儿」的小游戏。其实也没有错，这种方法是要找到待估算用户故事的相似点，团队的任务就是把相似的用户故事分组。「找相似」的最好做法是把这个过程可视化，并把分的过小的组合并成大组。
小贴士：这种方法在一小群人和少量用户故事中效果最好，你要给不同组别分配不同的估算值。
七、排序方法
这种做法能让你对用户故事的相对大小有比较准确的判断，如果是一小群专家做这件事会效果最好。
做法如下：把所有用户故事按照任意顺序放在一个从低到高的刻度标签上，每个参与者都能移动刻度上的一个用户故事，每次移动都只能往低或高移动一格，或者放弃一轮。一直重复这个过程，直到所有团队成员都不想再移动用户故事或者放弃一轮。
小贴士：这种排序的办法可以获得细颗粒度的估算，比较适合小群人和大量用户故事。
后记
这篇文章的目的只是向大家介绍这些方法的存在，在日常使用前，你应该根据自己用户故事和人员的规模，去尝试不同的办法。如果你对这些方法有兴趣，请在评论区留言。我打算展开讲讲每一种方法的实际使用~
