• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

敏捷团队必须做估算的四个理由

预测产品何时能够交付,并不是做估算最大的好处

当人们谈到用故事点进行估算时,常常有人问我:为什么敏捷团队要做估算?具体的说,为什么要对Product Backlog中的待办事项进行估算?

我能想到四个要做估算的好理由:建立团队口碑,促进深度思考,优先级排序,以及提供洞察力。

估算帮助团队在干系人中建立口碑

最有说服力的理由是,好的估算能帮助团队在干系人中建立良好的口碑。为什么这一点非常重要?让我们来看一个你可能很熟悉的场景。

你的组织中有人需要做一个新项目,假设只有四个月的时间。这可能是一个新产品,或是对现有产品的改进。

你的团队用估算扑克,斐波纳契数列,或是其他方法对工作量进行了估算。团队成员得出的结论是,四个月根本不可能交付。六个月看起来有可能,八个月是最理想的。于是团队回到干系人那里告诉他们,四个月项目做不完。并解释说,需要六到八个月的时间才能完成。

干系人回复说,无论如何项目还是得做,并且他们依旧希望能在四个月内完成。

干系人基本上忽略了团队的估算和计划。这么做是因为,这个团队可能一次又一次地证明了他们并不擅长估算这件事。团队过去的大部分项目大概率是一个接着一个的延期。

有着这样的一些名声,团队在交付日期的谈判中已经不再被视为一个平等的伙伴了。因为他们证明了自己无法确切的知道,在给定的时间内,能够交付多少东西。而干系人则不再对团队的估算抱有信任。

微信图片_20220527143557

现在想象另一个场景,团队在估算方面已经有所进步——并不完美,但做得更好了。他们表示一个项目需要花费三到四个月时间,而结果也的确如此。

相反,如果有一个团队,他们说一个项目需要花费四到五个月时间,结果比计划延迟了两个星期完成。在另一个五六个月的项目中,他们则提前了一个迭代完成交付。还有一次,尽管中途添加了计划外的新功能,团队依旧如期完成了项目。

这个团队建立了擅长敏捷估算的良好记录,当团队说项目需要六到八个月完成时,干系人愿意听。他们也许会失望,毕竟他们希望四个月完成。但这个情况下干系人不太可能向团队施压, 要求他们无论如何在四个月内完成。

当产品所需花的时间多于项目能给的时间时,这个团队理应被视为平等的伙伴,来共同做决定该做什么。成为这样的团队,唯一的办法就是要善于估算,并根据估算形成计划。

我认为这是一个非常有说服力的需要做估算的理由,但是让我再列举三个理由,说明为什么敏捷团队应该对Product Backlog进行估算。

估算确保团队停下来思考

第二个理由是,估算活动可以让团队对所要做的工作更加清晰。如果要给别人提供一个估计值,那么人们就倾向于更加仔细的考虑自己的工作,这是人的天性。

当我对一个用户故事做出估算时,我希望自己的估算是准确的,或至少是接近的。责任感驱使我更深入的进行思考,特别是涉及跨职能团队的工作。除了产生良好的估算外,这个过程还消除了许多真正会影响计划的大“惊喜”。

第三和第四个理由并不适用于所有团队,但如果适用于你的Scrum团队,它们将会是团队进行估算工作的重要理由。

估算帮助PO确定优先级排序

团队进行估算的第三个理由,是帮助Scrum团队的PO进行优先级排序。对Product Backlog中的待办事项的估算,将对PO如何排优先级产生影响。

如果一个待办事项的估算值是5个故事点,PO可能会希望团队在下个迭代就完成。

如果估算值是50个故事点,那么PO很可能会把它排到Backlog中靠后的位置,因为考虑到这50个故事点的花费,也许有其他更有价值的事项需要先完成。

如果估算结果是500个故事点,那么PO可能会把它放到Backlog的最底端,或者干脆从Backlog中移除,考虑到它需要耗费的成本如此之大。

微信图片_20220527143612

估算能够提供对交付的洞察力

最后,第四个要做估算的理由是,它使我们能够回答关于何时能交付多少产出的问题。

许多,也许是大部分团队常被问到的问题:

  • 什么时候能够完成全部这些功能?
  • 三个月内能交付这其中的多少功能?

当Product Backlog被恰当的估算后,团队就可以很好的回答这些问题。

如果没有对Product Backlog进行估算,那么团队就需要回退到传统的任务分解模式。他们必须对每个待办事项进行审查,分解成任务,再对每个任务进行估算,想办法发现哪些被遗漏了,再根据经验加上一些缓冲时间,并用全部这些努力来试图回答干系人的问题。

把每个待办事项分解成任务并进行估算,比直接对待办事项进行故事点估算的工作量要大得多得多。而实际上,我们在更高的层级上进行估算反而可以更准确,因为不依赖于完全识别出所有的子任务。毕竟,子任务可能会随着工作的进展而产生变化。

好口碑是敏捷团队成功的关键 

在这四个估算Product Backlog的理由中,我认为第一个理由是最有说服力的。直到团队的过往表现体现出了良好的估算和计划能力,他们才会在关于交付期限的谈判中受到平等的对待。否则后果将会是,你几乎没有能力拒绝一个被强加给团队的不合理的交付时间。

你怎么看? 

这四个关于估算的好处中,哪个能够更好的帮助到你的团队?团队中有哪些对估算的反对意见?你是否能说服他们进行估算?如何估算?请在评论区分享你的经验和观点。

 

原文地址:https://www.mountaingoatsoftware.com/blog/four-reasons-agile-teams-estimate-product-backlog-items

关于作者

【作者】Mike Cohn:Mike是敏捷联盟及Scrum联盟创始人之一,是帮助企业适应和改进敏捷过程及技术,以建立极致高效团队的专家。著有《用户故事与敏捷方法》,《敏捷估算与规划》,《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

【译者】Scrum中文网翻译组:Scrum中文网是全球第一个Scrum中文网站,中国最早的Scrum和敏捷教育及推广机构,也是国际Scrum联盟(ScrumAlliance)官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是国内领先的敏捷培训及教练咨询机构,作为中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。

Search
最新敏捷认证课 ~ 火热报名中
3月30-31日
Scrum Master (CSM) 认证课
张宁宁 Lance Zhang 授课
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280