在一篇2008年的文章中, Scott Ambler点明了提出成本问题背后的动机， 并指出多个来源，展示出：

　　敏捷方法比传统技术更为成功。

　　敏捷团队比传统团队更为高效。

　　敏捷项目比传统方法开发的产品质量更高。

　　敏捷项目的产出能让业务干系人更加满意。

　　敏捷项目比传统开发项目成本更低。

　　Ambler还提供了原始数据，这些数据引用自另一篇文章。

　　在LinkedIn的Agile Alliance 讨论组中有一篇很长的帖子谈到了该话题，并提出了一些观点：

　　很多时候，要度量知识工作者的工作效率是很困难的。

　　因为不可能将同一个项目在不同的方法论指导下完全做两次，所以要想做比较基本上是不可能的。

　　尽早反馈的价值，经常体现在没有犯错而节省的成本中。

　　敏捷项目会鼓励创新，从而产生能更好满足业务需求的产品，同时“将竞争对手远远抛在后面”。

　　Steve Gordon在讨论中指出：

　　在呼唤度量行为的背后，人们其实担心这样一个问题：以敏捷方式工作的知识工作者，他们的行为种类变化多样，很有可能不受控制。

　　人们可以指望敏捷来推动更快、更早的需求改进活动，这在传统的方式中很难做到(原因在于敏捷可以让人们对工作产出[working artifact]做出尽快、尽早的反馈，而且愿意做出改变)。改进需求，就能改进产出的东西。

　　仅仅度量原始的工作效率，这就完全丧失了上面提到的敏捷的重要效应。即使原始的工作效率数据有所下降(特别是在转换期)，如果因为频繁而具体的反馈，使得产出的东西更能发挥作用，更贴近产品目标，那么交付给客户的价值就很有可能大大增加。

　　不过接下来的问题就是：如何度量交付给客户的价值呢?我想你的客户对此的了解要远胜于其他人。这也要看市场的情况。在真正的垄断市场中，交付的数量也许要比产品是否合适或质量更重要。在另一些市场中，创新会让你把竞争对手远远落在后面，而不光是在性能对比表格上打打勾什么的。

　　有意思的是，CNN将敏捷看做对软件开发管理层面的影响，并在《影响未来商业世界的50个人、产品、趋势和想法》这篇文章中进行了报道：

　　敏捷团队行动非常迅速，他们创建很小块的代码，工作周期有时甚至只有一周时间。完成某个组件后，就会添加新功能，这个过程会一直重复下去。敏捷在帮助管理层按时按预算交付产品方面也享有盛名，这也解释了为什么像Google和洛克希德•马丁这样的公司会选它作为方法论。

　　这样的宣传和支持，是否有利于敏捷实践在商业世界中推广和实施呢?