除了計劃撲克,還有這些用戶故事估算方法
說到敏捷估算,就不能不提到它的基本原則:使用相對的估算單位(比如:故事點),提倡詳細討論估算用戶故事的內容,對解決方案形成共識并作出承諾,并通過協作增強團隊凝聚力。
我身邊的不少敏捷團隊都會用「計劃撲克」來估算故事點,不過這種方法雖然流行,卻也有它的限制,比如說:待估算的功能過大,用「計劃撲克」弄不好估算出 300 個故事出來;或者待估算的用戶故事沒有足夠的信息作參照;再或者時間緊迫,來不及預估整個產品需求列表。
那么,除了「計劃撲克」,還有哪些敏捷估算的方法呢?
今天我就用這篇文章來講講七種敏捷估算的方法:
一、計劃撲克
所有參與的人都用帶編號的撲克牌來估算用戶故事,估算時匿名投票,如果出現較大分歧時展開討論,然后再次投票,直到整個團隊就估計的準確性達到共識。計劃撲克的使用有局限性,最適合小團隊(5 – 8 人)和少量用戶故事(最多不超過 10 個)的估計。
小貼士:把估值控制在你們 hold 得住的范圍內,不要超過十三點(一語雙關)。
二、T 恤尺碼
用 T 恤的尺碼來估算用戶故事大小:XS、S、M、L、XL。每個尺碼代表多大,需要團隊進行開誠布公的討論。這個辦法很簡單快捷,可以粗線條地估算產品需求列表的大小。
小貼士:這種方法適合估算大型用戶故事的海量需求列表,尤其是幾個 Scrum 團隊都圍繞一個產品工作的情況。
三、點投票
這種方法適合估算小用戶故事,且方法本身十分簡單有效?!更c投票」本是一種決策方式,但你也可以把它用在估算用戶故事上。方法是:每個人分到幾張便利貼,自由選擇為哪些用戶故事投票。一個用戶故事得到的點數越多,代表著它體量越大。
小貼士:這種方法在大小團隊里都可以使用,但你要去限制被估算用戶故事的數量。
四、水桶體系
如果你要找一種比計劃撲克效率高的估算方式,則非「水桶體系」莫屬了。如果需要估算多人參與的多個用戶故事時,「水桶體系」就可以發揮優勢。首先,按照「計劃撲克」的順序,用棕色的紙張折幾個「水桶」。然后,團隊把待估算用戶故事寫在便利貼上,放入「水桶」估算。
小貼士:如果你打算忽略掉已經討論過的用戶故事,也可以在估算過程里使用真正的水桶。
五、三分法
「大、不確定、小」三分法是一種非??旖莸拇致怨浪惴椒ǎ@種方法要求團隊把每個用戶故事都歸于這三類之一。首先,把容易確定的用戶故事歸位到大、小兩個類別下;然后,再集體討論剩下難以歸類的用戶故事;最后,為這三個類別確定各自的大小。
小貼士:這個辦法實際上是「水桶體系」的簡化版,特別適合那些手頭用戶故事有可比性的小團隊。
六、找相似
乍一看,你可能以為這種方法像那種「連連看」、「找茬兒」的小游戲。其實也沒有錯,這種方法是要找到待估算用戶故事的相似點,團隊的任務就是把相似的用戶故事分組?!刚蚁嗨啤沟淖詈米龇ㄊ前堰@個過程可視化,并把分的過小的組合并成大組。
小貼士:這種方法在一小群人和少量用戶故事中效果最好,你要給不同組別分配不同的估算值。
七、排序方法
這種做法能讓你對用戶故事的相對大小有比較準確的判斷,如果是一小群專家做這件事會效果最好。
做法如下:把所有用戶故事按照任意順序放在一個從低到高的刻度標簽上,每個參與者都能移動刻度上的一個用戶故事,每次移動都只能往低或高移動一格,或者放棄一輪。一直重復這個過程,直到所有團隊成員都不想再移動用戶故事或者放棄一輪。
小貼士:這種排序的辦法可以獲得細顆粒度的估算,比較適合小群人和大量用戶故事。
后記
這篇文章的目的只是向大家介紹這些方法的存在,在日常使用前,你應該根據自己用戶故事和人員的規模,去嘗試不同的辦法。如果你對這些方法有興趣,請在評論區留言。我打算展開講講每一種方法的實際使用~
本文由 @?即能 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Pixabay,基于 CC0 協議
- 目前還沒評論,等你發揮!