我们真的不擅长估算吗？

译者序：在十数年的工作经历中，我见到过很多团队由于估算的失误而陷入沮丧，甚至开始怀疑估算的意义和价值，并最终放弃估算。本文通过浅显的实例、数据与文献的佐证，给出了令人宽慰与充满信心的结论。其中，部分观点还意外的有趣。

  本文作者Mike Cohn是敏捷联盟和Scrum联盟的联合创始人，在这两家公司的董事会中任职多年，是《Scrum敏捷软件开发》的作者。如果你对敏捷比较熟悉，那你对这位大师你一定不会觉得陌生。本文为原创翻译，并已获得作者授权。

 我们真的不擅长估算吗？

估算一直是个有争议的话题。团队有时候不愿意进行估算，因为害怕老板会用最初估算的结果去挑战他们。客户和利益干系人总是想知道交付工作的具体内容和时间，但如果工作是全新的或者不熟悉的，你又该如何进行估算呢？如果你身处一个充斥着错误估算的环境，你是否觉得应该完全跳过估算而选择直接开工？

很多围绕估算的挫折和问题最终可能都能归结到这样的一个想法：估算这种事情，本来就是人类所不擅长的。

但事实真的如此吗？

 我们实际上很擅长估算

对于某些估算，我们真的非常擅长。

例如，今天晚些时候，我打算再写一篇博文。我估算完成初稿需要两个小时。我确定一定以及肯定不会花费正好两个小时， 也许需要一个半小时到三个小时。但是作为一个下午的日程安排计划，这是一个很好的估算。

当我亲自教授认证ScrumMaster®课程时，我会前一天安排和布置培训室。我会为班上的每个人准备很多用品，在墙上挂一些海报等等。根据我的经验，通常一个的房间布置需要45分钟。我已经上了这么多的认证ScrumMaster课程了，我对这个估算相当有信心。

大多数日子里，你可能发现自己正在估算许多类似的事务：固定的晚餐、开车去朋友家，去超市购物等等，估算的结果通常也很靠谱。

我们非常擅长估算这类事务，因为我们对它们有一定程度的熟悉。我们只是不太擅于估算我们不熟悉的事情。

数据表明，我们的估算并没有那么糟糕。奥斯陆大学教授、西穆拉研究实验室首席科学家马格尼·约尔根森在对现有估算研究的报告中指出，大多数估算准确率在20%到30%以内。在软件项目上，他并没有发现总体估算值过低的趋势：

历史上大量的时间预测失败可能会给人一种印象，即我们的时间预测能力很差，而且失败比想到的少数成功要 多 得多。我们认为，这是一个不公平的评价。人类预测时间使用的能力通常令人印象深刻。它使我们能够成功实现各种重要目标，从控制复杂的建筑工程到协调家庭聚会。毫无疑问，人类的时间预测能力是出奇 好 并且 非常有用的。不幸的是，它有时辜负了我们。·马格内·约尔根森

但如果我们不是估算得太糟糕，那为什么我们会有这样的共识呢？

“一个从未被启动的项目”

想象一下，一个老板向团队描述新产品。老板在批准或拒绝项目工作之前想要一个估算值。假设项目如果完成，实际上需要 1000 小时。当然，我们还不知道实际情况，因为团队刚才被要求提供一个估算。

对于这个案例，我们设想团队估算项目需要 500 小时。

老板对此很满意，并批准了这个项目。

但是团队花费1000个小时的才完成工作。项目完成花费的时间太久了（对比估算）。拖了多么久，以至于每个项目组成员都留下了一个难忘的记忆。

现在让我们想象另一个在平行宇宙中的场景。老板向团队要求估算同一个项目。该小组估算需要1500个小时。

（请记住，我们都知道此项目实际上需要 1000 小时，但团队还不知道这一点。）

那么会发生什么呢？

团队是否会提前交付，然后开个庆功会？

不。因为当老板听说这个项目需要1500个小时的时候，她决定不做了，决定放弃这个项目。这个项目耗时太久了，看不到光明的未来，但是没有人知道是因为团队过度估算了。

被“低估”的项目比被“高估”的项目更有可能获得批准。这就会导致“开发团队总是延期”这样的结论，但事实上，那些被高估的项目可能已经被毙掉了。

我们的过度自信经常导致不正确的估算

正如我所提到的，我们不一定不擅长估算，但我们一定会估错。根据我的经验，这通常源于我们对估算能力过于自信。

我以前做过一个练习来帮助人们看到这一点：我在课堂上问了一系列10个问题，要求人们给我一个范围，他们90%的自信会包含正确答案。

例如，我会要求你估算歌手猫王是何时出生的。我需要你给我一个年代的范围， 这位年代范围有90% 肯定将包含正确的答案。如果你是猫王的超级粉丝， 你就会知道他出生的那一年。你甚至可能知道确切的日期，因此，你不太可能需要给一个年代范围。

但是，假设你是猫王的纯路人，你给出的年代范围会更广。

你可能会先想，“他是不是在五十年代发现了一些热门唱片专辑？亦或是在六十年代？”

记住我们的游戏规则，我需要你给我一个年代范围，你90%有信心在范围中包含正确的一年。你可能会想，如果猫王在20岁时录制唱片，并在50年代有热门歌曲，那么他出生初期的一年可能是1930年。

如果他在六十年代录音，也许他直到1940年才出生。

因此，你给出的年代范围是：1930-1940。

恭喜你答对了，猫王出生于1935年。

猫王是一位名人，他活着的时候很多人都很熟悉他，所以答对并不是一件难事。

但是，对于我的其他问题，可能给出的答案范围就很难缩小。例如，我可能会问2019年售出多少台iPad，或者有多少运动员参加了2016年奥运会，或者塞纳河的长度。

我们的游戏规则保持不变，对于每个问题，需要确保以下两点：

1.提供一系列您认为包含正确答案的数字范围（单位/运动员人数/英里等）。

2.90% 确信正确答案在该范围内。

结果是令人惊讶的！即使我告诉他们给我90%的肯定范围，但大多数人把大多数问题都搞错了。

他们给出的范围通常比他们对不熟悉领域的提问应该给出的范围要小得多。

例如，假设我不知道 2019 年售出多少台 iPad。如果我想 90% 确定我给的范围包含正确的答案， 我应该提供一个巨大的范围， 从0到 10 亿。当然这个范围有点夸张了，但我会有信心这里面包含了正确答案。

以我的经验来看，人们给出的范围越窄，越是高估了自己准确估算的能力。

以上都是这个观点的简单例证，此外有许多研究表明我们在做预测时过于自信。

  我们能做得更好吗？数据表明这是可能的（通过团队讨论）

当估算过于自信的证据被狠狠拍在人们脸上的同时，有数据表明，我们每个“估算者”确实在进步。

在一项软件开发工作的研究中，研发人员对前10个项目能给出64%估算准确率，在经过估算讨论之后，他们在第二组10个项目的估算中正确率提升为 70% 。又经过一轮讨论后，到了第三组，正确率已经提升到了81%。

让估算者认识到对自己估算能力的过度自信是错误的，这有助于鼓励协作式估算方法（团队估算）。

如果有人完全相信自己的估算是万无一失的， 那这个人就不会建设性地参与到正确估算的讨论中去。

你有什么想法？

你认为我们不擅长估算的看法是不公平的吗？你和你的团队在合作时能够提高估计值吗？你是怎么做的？请在评论区里给我留言。

附上原文：

https://www.mountaingoatsoftware.com/blog/are-we-really-bad-at-estimating

   Are We Really Bad at Estimating?

The topic of estimating can be a contentious one. Teams may be reluctant to estimate for fear of creating something stakeholders will use against them. Clients and stakeholders will always want to know what will be delivered and when, but how do you predict this if the work is new or unfamiliar? And if you work in an environment where estimates are usually wrong, should you skip estimating altogether and just get on with building something?

I believe a lot of the frustration and issues surrounding estimates stems from the belief that, as humans, we’re just bad at estimating.

But I don’t think that’s true.

   We’re Actually Pretty Good at Estimating (Some Things)

Don’t get me wrong—we’re definitely bad at estimating some things. But others we’re quite adept at.

For example, later today I plan to write another blog post. I estimate it will take two hours to complete the first draft of that. I’m pretty sure it won’t take exactly two hours but it will probably take between one-and-a-half and three hours. For the purpose of planning my afternoon, that’s a good estimate.

Back when I was teaching in-person Certified ScrumMaster® courses, I would set up the room the day before. I would put a lot of supplies out for each person in the class. I had to hang some posters on the wall. And so on. From experience, I’d estimate that a typical room set-up would take 45 minutes. I’ve set up for so many Certified ScrumMaster courses that I feel fairly confident in that estimate.

There are probably a myriad of similar tasks that you find yourself estimating (successfully) most days—whether it’s fixing dinner, driving to a friend’s house, or going grocery shopping.

We’re pretty good at estimating these things because we have a certain level of familiarity with them. We’re not as good at estimating things we aren’t familiar with.

Data supports my claim that we’re not really that bad at estimating. In a review of the existing research on estimates, University of Oslo professor and Chief Scientist at the Simula Research Laboratory Magne Jørgensen found most estimates to be within 20 to 30% of actuals. And on software projects, he did not find an overall tendency for estimates to be too low:

The large number of time prediction failures throughout history may give the impression that our time prediction ability is very poor and that failures are much more common than the few successes that come to mind. This is, we think, an unfair evaluation. The human ability to predict time usage is generally highly impressive. It has enabled us to succeed with a variety of important goals, from controlling complex construction work to coordinating family parties. There is no doubt that the human capacity for time prediction is amazingly good and extremely useful. Unfortunately, it sometimes fails us. –Magne Jørgensen

But if we’re not too bad at estimating, why is there a common perception that we are?

   One Answer Lies in the Projects We Never Start

Imagine a boss who describes a new product to a team. The boss wants an estimate before approving or rejecting work on the project. Let’s suppose the project, if played out, would actually take 1,000 hours. Of course, we don’t know that yet, since the team is just now being asked to provide an estimate.

For this example, let’s imagine the team estimates the project will take 500 hours.

The boss is happy with this and approves the project.

But…in the end it takes 1,000 hours of work to complete. It comes in late and everyone involved is left with a vivid memory of how late it was.

Let us now imagine another scenario playing out in a parallel universe. The boss approaches the team for an estimate of the same project. The team estimates it will take 1,500 hours.

(Remember, you and I know this project is actually going to take 1,000 hours but the team doesn’t know that yet.)

So what happens?

Does the team deliver early and celebrate?

No. Because when the boss hears that the project is going to take 1,500 hours, she decides not to do it. This project never sees the light of day and no one ever knows that the team overestimated.

A project that is underestimated is much more likely to be approved than a project that is overestimated. This leads to a perception that development teams are always late, but it just  looks that way because teams didn’t get to run the projects they had likely overestimated.

   Our Overconfidence Often Leads to Incorrect Estimates

As I mentioned, we’re not necessarily bad at estimating, but we can definitely get it wrong. In my experience, this usually stems from an overconfidence in our ability to estimate.

I’ve done an exercise previously to help people see this: I ask a series of ten questions in class and ask people to provide me with a range that they are 90% confident will contain the answer.

For example, I might ask you to estimate when the singer Elvis Presley was born. And I ask you to give me a range of years that you are 90% certain will contain the correct answer. If you’re a huge Elvis fan, you’ll know the year he was born. You might even know the exact date, and as a result, you wouldn’t likely need to give a range of years

But let’s say you’re less of a fan, and your range is going to be wider.

You might start by thinking, “Didn’t he have some hit records in the fifties? Or was it the sixties?”

Remember, I want you to give me a range of years that you are 90% confident will contain the correct year. You might then think that if Elvis was recording at the age of 20, and had hits in the fifties, an early year of his birth could be 1930.

And at the upper range, if he was recording in the sixties, perhaps he wasn’t born until 1940.

So your range might be: 1930–1940.

And in this case, you’d be correct, since Elvis was born in 1935.

But Elvis was an iconic figure and many people will be familiar with when he was alive.

So for my other questions I deliberately ask for answers that might be more difficult to narrow down. For example I might ask how many iPads were sold in 2019, or how many athletes competed in the 2016 Olympics, or for the length of the Seine River.

Now, for each question, the parameters remain the same:

· Provide a range of numbers (units/athletes/miles, etc.) that you think contains the correct answer.

· Be 90% confident that the correct answer is within that range.

What happens is surprising! Even though I tell them to give me ranges that are 90% certain of, most people get most questions wrong.

The ranges they provide are usually much smaller than they should be when considering their unfamiliarity with the subject.

For example, let’s imagine that I have no idea how many iPads were sold in 2019. If I want to be 90% certain the range I give contains the correct answer, I should provide a huge range, say zero to one billion. That would be widely exaggerated, but I’d be confident in my answer.

In my experience, the ranges people pick are narrower, suggesting that we overestimate our own ability to estimate accurately.

Obviously this is a simplified illustration, but there are a number of studies that suggest we are overconfident when it comes to forecasting.

   Can We Get Better? The Data Suggests It’s Possible (with Feedback)

When people are presented with evidence of their overconfidence, there’s data to show that individual estimators do improve.

In one study of software development work, programmers gave correct estimates 64% of the time on the first ten items they estimated.

When provided with that feedback, they improved to 70% correct on the second set of ten items. And then to 81% on the third set, after additional feedback on their accuracy.

Getting estimators to realize that excessive confidence in their own estimating abilities is misplaced is helpful to encourage a collaborative approach to estimating.

If someone is absolutely convinced of the infallibility of their own estimates, that person won’t engage constructively in debates about the right estimate to provide.