虽然产品Backlog的估算很重要，但是并不是所有的团队都需要做估算。那些做估算的团队更需要了解的是为什么要做估算，而不仅仅是如何去做估算。我们估算产品Backlog主要有两个原因：
首先，估算产品backlog条目帮助PO对产品backlog进行排序。
每个估算值意味着每个条目的实现成本。如果不了解一个条目的实现成本，PO不可能对其进行正确的排序。就像如果我不知道各种品牌车型的价格，我会把法拉利排在我欲购车型的首位，其次是兰博基尼和特斯拉。但是，喔，一旦我了解它们的价格，我就会调整我的购车列表优先级。
在不清楚成本的情况下，PO能清楚地知道他或她到底有多么的需要去实现一个产品backlog条目。但是，要对条目进行正确排序的话，PO最终还是需要知道条目的实现成本。
第二个原因是，通过估算可以对项目做一个长期的预估。
假如老板/客户想知道开发团队何时能完成一组产品backlog条目，这组产品backlog条目就需要进行估算。类似的情况，老板/客户想知道在3个月内能交付多少功能的话，大概3个月里能完成的条目也需要被估算一下。
一些PO除了对工作进行非常简单的排序之外，并不需要对其进行更详细的优先级的区分。另一些PO自己能对估算做足够好的猜测，所以他们就可以在不打扰团队的情况下对其进行优先级设置了。而在一些公司，可能没必要想相关部门告知几个月之后团队将工作进行到哪里了或将交付哪些实现的条目。在这些情况下，就没必要估算产品backlog条目。
尽管如此，估算还是有些好处的。比如，被要求估算的话会强迫团队在进行工作之前对工作内容进行思考，而这是有价值的。（不过,要求团队做这个显然也是一种成本。）
了解为什么要估算产品 backlog条目还能帮助解决我经常看到的一个普遍性问题：在正确的时间估算产品backlog。产品backlog需要被尽早的估算,以便对其进行排序或者回答上面那些何时交付/交付多少的问题。
在sprint计划会议时为产品backlog条目订出故事点上简直太晚了，PO无法获得上文中提到的好处。还有其他的问题，那么晚订出故事点让PO无法为本次sprint及时地获取新信息。这就像是你等到我都相中法拉利了才告诉我，“顺便说一下，这些车很贵的。” 这对阻止我进行一次昂贵的采购来说可能足够早，但对我快速的找出哪些车才应该要关注的却不够早。
如果你的PO不需要估算来设置优先级，或者没人要求你预测多个sprint后能交付什么,那就不必麻烦地为你的产品backlog订出故事点。但是，如果你的项目能从估算获益，那就早一点进行而不是等到sprint计划会议时，这样PO就能有时间根据新信息进行思考并采取行动。
作者:Mike Cohn
（Scrum中文网经授权翻译及转载，不得复制）
