除了计划扑克,还有这些用户故事估算方法

15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

说到敏捷估算,就不能不提到它的基本原则:使用相对的估算单位(比如:故事点),提倡详细讨论估算用户故事的内容,对解决方案形成共识并作出承诺,并通过协作增强团队凝聚力。

我身边的不少敏捷团队都会用「计划扑克」来估算故事点,不过这种方法虽然流行,却也有它的限制,比如说:待估算的功能过大,用「计划扑克」弄不好估算出 300 个故事出来;或者待估算的用户故事没有足够的信息作参照;再或者时间紧迫,来不及预估整个产品需求列表。

那么,除了「计划扑克」,还有哪些敏捷估算的方法呢?

今天我就用这篇文章来讲讲七种敏捷估算的方法:

一、计划扑克

所有参与的人都用带编号的扑克牌来估算用户故事,估算时匿名投票,如果出现较大分歧时展开讨论,然后再次投票,直到整个团队就估计的准确性达到共识。计划扑克的使用有局限性,最适合小团队(5 – 8 人)和少量用户故事(最多不超过 10 个)的估计。

小贴士:把估值控制在你们 hold 得住的范围内,不要超过十三点(一语双关)。

二、T 恤尺码

用 T 恤的尺码来估算用户故事大小:XS、S、M、L、XL。每个尺码代表多大,需要团队进行开诚布公的讨论。这个办法很简单快捷,可以粗线条地估算产品需求列表的大小。

小贴士:这种方法适合估算大型用户故事的海量需求列表,尤其是几个 Scrum 团队都围绕一个产品工作的情况。

三、点投票

这种方法适合估算小用户故事,且方法本身十分简单有效。「点投票」本是一种决策方式,但你也可以把它用在估算用户故事上。方法是:每个人分到几张便利贴,自由选择为哪些用户故事投票。一个用户故事得到的点数越多,代表着它体量越大。

小贴士:这种方法在大小团队里都可以使用,但你要去限制被估算用户故事的数量。

四、水桶体系

如果你要找一种比计划扑克效率高的估算方式,则非「水桶体系」莫属了。如果需要估算多人参与的多个用户故事时,「水桶体系」就可以发挥优势。首先,按照「计划扑克」的顺序,用棕色的纸张折几个「水桶」。然后,团队把待估算用户故事写在便利贴上,放入「水桶」估算。

小贴士:如果你打算忽略掉已经讨论过的用户故事,也可以在估算过程里使用真正的水桶。

五、三分法

「大、不确定、小」三分法是一种非常快捷的粗略估算方法,这种方法要求团队把每个用户故事都归于这三类之一。首先,把容易确定的用户故事归位到大、小两个类别下;然后,再集体讨论剩下难以归类的用户故事;最后,为这三个类别确定各自的大小。

小贴士:这个办法实际上是「水桶体系」的简化版,特别适合那些手头用户故事有可比性的小团队。

六、找相似

乍一看,你可能以为这种方法像那种「连连看」、「找茬儿」的小游戏。其实也没有错,这种方法是要找到待估算用户故事的相似点,团队的任务就是把相似的用户故事分组。「找相似」的最好做法是把这个过程可视化,并把分的过小的组合并成大组。

小贴士:这种方法在一小群人和少量用户故事中效果最好,你要给不同组别分配不同的估算值。

七、排序方法

这种做法能让你对用户故事的相对大小有比较准确的判断,如果是一小群专家做这件事会效果最好。

做法如下:把所有用户故事按照任意顺序放在一个从低到高的刻度标签上,每个参与者都能移动刻度上的一个用户故事,每次移动都只能往低或高移动一格,或者放弃一轮。一直重复这个过程,直到所有团队成员都不想再移动用户故事或者放弃一轮。

小贴士:这种排序的办法可以获得细颗粒度的估算,比较适合小群人和大量用户故事。

后记

这篇文章的目的只是向大家介绍这些方法的存在,在日常使用前,你应该根据自己用户故事和人员的规模,去尝试不同的办法。如果你对这些方法有兴趣,请在评论区留言。我打算展开讲讲每一种方法的实际使用~

 

本文由 @ 即能 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Pixabay,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
圈子
关注微信公众号
大家都在问