說到敏捷估算，就不能不提到它的基本原則：使用相對的估算單位（比如：故事點），提倡詳細討論估算用戶故事的內容，對解決方案形成共識并作出承諾，并通過協作增強團隊凝聚力。

我身邊的不少敏捷團隊都會用「計劃撲克」來估算故事點，不過這種方法雖然流行，卻也有它的限制，比如說：待估算的功能過大，用「計劃撲克」弄不好估算出 300 個故事出來；或者待估算的用戶故事沒有足夠的信息作參照；再或者時間緊迫，來不及預估整個產品需求列表。

那么，除了「計劃撲克」，還有哪些敏捷估算的方法呢？

今天我就用這篇文章來講講七種敏捷估算的方法：

一、計劃撲克

所有參與的人都用帶編號的撲克牌來估算用戶故事，估算時匿名投票，如果出現較大分歧時展開討論，然后再次投票，直到整個團隊就估計的準確性達到共識。計劃撲克的使用有局限性，最適合小團隊（5 – 8 人）和少量用戶故事（最多不超過 10 個）的估計。

小貼士：把估值控制在你們 hold 得住的范圍內，不要超過十三點（一語雙關）。

二、T 恤尺碼

用 T 恤的尺碼來估算用戶故事大?。篨S、S、M、L、XL。每個尺碼代表多大，需要團隊進行開誠布公的討論。這個辦法很簡單快捷，可以粗線條地估算產品需求列表的大小。

小貼士：這種方法適合估算大型用戶故事的海量需求列表，尤其是幾個 Scrum 團隊都圍繞一個產品工作的情況。

三、點投票

這種方法適合估算小用戶故事，且方法本身十分簡單有效?！更c投票」本是一種決策方式，但你也可以把它用在估算用戶故事上。方法是：每個人分到幾張便利貼，自由選擇為哪些用戶故事投票。一個用戶故事得到的點數越多，代表著它體量越大。

小貼士：這種方法在大小團隊里都可以使用，但你要去限制被估算用戶故事的數量。

四、水桶體系

如果你要找一種比計劃撲克效率高的估算方式，則非「水桶體系」莫屬了。如果需要估算多人參與的多個用戶故事時，「水桶體系」就可以發揮優勢。首先，按照「計劃撲克」的順序，用棕色的紙張折幾個「水桶」。然后，團隊把待估算用戶故事寫在便利貼上，放入「水桶」估算。

小貼士：如果你打算忽略掉已經討論過的用戶故事，也可以在估算過程里使用真正的水桶。

五、三分法

「大、不確定、小」三分法是一種非?？旖莸拇致怨浪惴椒?，這種方法要求團隊把每個用戶故事都歸于這三類之一。首先，把容易確定的用戶故事歸位到大、小兩個類別下；然后，再集體討論剩下難以歸類的用戶故事；最后，為這三個類別確定各自的大小。

小貼士：這個辦法實際上是「水桶體系」的簡化版，特別適合那些手頭用戶故事有可比性的小團隊。

六、找相似

乍一看，你可能以為這種方法像那種「連連看」、「找茬兒」的小游戲。其實也沒有錯，這種方法是要找到待估算用戶故事的相似點，團隊的任務就是把相似的用戶故事分組?！刚蚁嗨啤沟淖詈米龇ㄊ前堰@個過程可視化，并把分的過小的組合并成大組。

小貼士：這種方法在一小群人和少量用戶故事中效果最好，你要給不同組別分配不同的估算值。

七、排序方法

這種做法能讓你對用戶故事的相對大小有比較準確的判斷，如果是一小群專家做這件事會效果最好。

做法如下：把所有用戶故事按照任意順序放在一個從低到高的刻度標簽上，每個參與者都能移動刻度上的一個用戶故事，每次移動都只能往低或高移動一格，或者放棄一輪。一直重復這個過程，直到所有團隊成員都不想再移動用戶故事或者放棄一輪。

小貼士：這種排序的辦法可以獲得細顆粒度的估算，比較適合小群人和大量用戶故事。

后記

這篇文章的目的只是向大家介紹這些方法的存在，在日常使用前，你應該根據自己用戶故事和人員的規模，去嘗試不同的辦法。如果你對這些方法有興趣，請在評論區留言。我打算展開講講每一種方法的實際使用~

本文由 @?即能 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Pixabay，基于 CC0 協議