预测产品何时能够交付，并不是做估算最大的好处
当人们谈到用故事点进行估算时，常常有人问我：为什么敏捷团队要做估算？具体的说，为什么要对Product Backlog中的待办事项进行估算？
我能想到四个要做估算的好理由：建立团队口碑，促进深度思考，优先级排序，以及提供洞察力。
估算帮助团队在干系人中建立口碑
最有说服力的理由是，好的估算能帮助团队在干系人中建立良好的口碑。为什么这一点非常重要？让我们来看一个你可能很熟悉的场景。
你的组织中有人需要做一个新项目，假设只有四个月的时间。这可能是一个新产品，或是对现有产品的改进。
你的团队用估算扑克，斐波纳契数列，或是其他方法对工作量进行了估算。团队成员得出的结论是，四个月根本不可能交付。六个月看起来有可能，八个月是最理想的。于是团队回到干系人那里告诉他们，四个月项目做不完。并解释说，需要六到八个月的时间才能完成。
干系人回复说，无论如何项目还是得做，并且他们依旧希望能在四个月内完成。
干系人基本上忽略了团队的估算和计划。这么做是因为，这个团队可能一次又一次地证明了他们并不擅长估算这件事。团队过去的大部分项目大概率是一个接着一个的延期。
有着这样的一些名声，团队在交付日期的谈判中已经不再被视为一个平等的伙伴了。因为他们证明了自己无法确切的知道，在给定的时间内，能够交付多少东西。而干系人则不再对团队的估算抱有信任。
现在想象另一个场景，团队在估算方面已经有所进步——并不完美，但做得更好了。他们表示一个项目需要花费三到四个月时间，而结果也的确如此。
相反，如果有一个团队，他们说一个项目需要花费四到五个月时间，结果比计划延迟了两个星期完成。在另一个五六个月的项目中，他们则提前了一个迭代完成交付。还有一次，尽管中途添加了计划外的新功能，团队依旧如期完成了项目。
这个团队建立了擅长敏捷估算的良好记录，当团队说项目需要六到八个月完成时，干系人愿意听。他们也许会失望，毕竟他们希望四个月完成。但这个情况下干系人不太可能向团队施压， 要求他们无论如何在四个月内完成。
当产品所需花的时间多于项目能给的时间时，这个团队理应被视为平等的伙伴，来共同做决定该做什么。成为这样的团队，唯一的办法就是要善于估算，并根据估算形成计划。
我认为这是一个非常有说服力的需要做估算的理由，但是让我再列举三个理由，说明为什么敏捷团队应该对Product Backlog进行估算。
估算确保团队停下来思考
第二个理由是，估算活动可以让团队对所要做的工作更加清晰。如果要给别人提供一个估计值，那么人们就倾向于更加仔细的考虑自己的工作，这是人的天性。
当我对一个用户故事做出估算时，我希望自己的估算是准确的，或至少是接近的。责任感驱使我更深入的进行思考，特别是涉及跨职能团队的工作。除了产生良好的估算外，这个过程还消除了许多真正会影响计划的大“惊喜”。
第三和第四个理由并不适用于所有团队，但如果适用于你的Scrum团队，它们将会是团队进行估算工作的重要理由。
估算帮助PO确定优先级排序
团队进行估算的第三个理由，是帮助Scrum团队的PO进行优先级排序。对Product Backlog中的待办事项的估算，将对PO如何排优先级产生影响。
如果一个待办事项的估算值是5个故事点，PO可能会希望团队在下个迭代就完成。
如果估算值是50个故事点，那么PO很可能会把它排到Backlog中靠后的位置，因为考虑到这50个故事点的花费，也许有其他更有价值的事项需要先完成。
如果估算结果是500个故事点，那么PO可能会把它放到Backlog的最底端，或者干脆从Backlog中移除，考虑到它需要耗费的成本如此之大。
估算能够提供对交付的洞察力
最后，第四个要做估算的理由是，它使我们能够回答关于何时能交付多少产出的问题。
许多，也许是大部分团队常被问到的问题：
- 什么时候能够完成全部这些功能？
- 三个月内能交付这其中的多少功能？
当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中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
