scrum的哲学是“只关心当前sprint的精确估算，对于长期的开发计划保持粗略。我不知道将来会如何，我只知道当前在做最正确的事。”，但这种思路很难被管理层接受，很多时候，我们被要求对整个项目进行估算——虽然很可能这些估算都会因各种各样的实际情况而在开发过程中面目全非甚至作废。但，没办法，这是管理层习惯的管理方法。
如果遇到这样的情况，怎么处理呢？肯思瓦伯在《应用scrum进行软件项目管理》里的答案是“我也不知道”。ok，那么很明显，如果你要应用敏捷，首先一定要让管理层接受scrum的哲学，改变他们的思维方式。另外，infoq上的这篇文章可以看看《超越短期的scrum项目估算》：http://www.infoq.com/cn/news/2011/01/scrum-project-estimation
============================================================================
Peter Bell对估算与承诺进行了严格的区分：
是否有人问过你关于估算或是承诺的问题呢？所谓估算，就是根据目前可用的信息做出的合理猜测。估算不是偏高就是偏低，通常在构建复杂软件时估算会偏低。他们不是承诺，也不能当作承诺。Scrum Development邮件列表上的成员所达成的共识是项目估算并非特别有用，也不值得你花很多时间在这上面。
“woynam”写到：
进行估算的组织请不要再忧虑某些东西要花费多少代价了，请转到变化上来吧。如果你知道要花费多少代价、要花费多少时间，那么唯一变化的就是你的这些钱会实现多少个高优先级的特性了。关键在于如果你不再进行估算， 那么你仍旧可以确保首先实现最有价值的那些特性。George Dinwiddie写到：
如果利润或是损失取决于对花费的精准预测，那么你可能选错产品了。这种产品的升值潜力太低了。我经常发现组织中的高层很清楚这一点，但中层经理往往不太理解：
对于大多数组织来说，估算都不是什么好事：他们被当作承诺和威胁，还会导致人们机械化地决定工作量、增加故事点或是小时数，而非仔细洞察团队到底能完成什么，如何完成。我完全不赞成对故事进行估算，除了这样的描述：“几个人干几天”。当然了，这仍然是估算，但却不易被误用。
我喜欢让团队在几周内对大的故事进行估算，然后不断累加。这么做的结果会让人们对项目大小形成一种共识。不能将这当作承诺，但可以作为一个点，你可以提出重要的问题，比如说：在N美元和M月的前提下， 我们能否交付呢？