如何度量敏捷软件开发所能交付的业务价值？当定义一个业务场景实施敏捷时，这个问题就会出现。

在博文《敏捷指标：度量过程价值》中，Michael Moore对为什么度量敏捷交付的价值很重要进行了说明：

（……）敏捷不只是跟效率有关，它还关注成效（价值交付）。毕竟，如果一个过程/方法能够让你做事更快速/便捷，但最终却没能向终端用户交付更多的价值，那它有什么好呢？因此，敏捷承诺降低成本和增加收益。

因此，如果你注重效率的提升，而且这可能是你采用敏捷的唯一理由，那么你很可能会看到预期的结果；产品交付更快了。但是，如果在这个过程中不注重增加收益/价值（比如，产品结果），那么最终你真的只是延缓了组织不可避免的死亡。没有任何降低的成本可以弥补生产收益的缺乏。

Michael谈到了使用所谓的“海盗指标（pirate metrics）”度量敏捷的价值：获取、激活、保持、转介和收益。当度量价值的时候，最初应该关注提供敏捷获取相关信息的指标。当获取增加，则关注重点可以转向度量激活：

用这个模型做例子，如果将它应用到敏捷转型的运营和过程方面，我们会考虑用什么指标呢？收益的等价物是速度吗（我知道，不能比较！）？所有参加新人训练营的人都会成为敏捷转型的参与者吗？

早些时候，关于敏捷实施的度量我们采访了Capers Jones。他提到了几个可以在方法迁移时使用的基本测量值；这些指标可以用于度量敏捷的价值：

为了度量生产力，世界上两个使用最广泛的测量值是“每人月的功能点数”和它的倒数，“每个功能点的工时”。对于评判生产力而言，速度超过每人月10个功能点则相当不错；速度小于每人月7个功能点则不是那么好。有些敏捷项目已经超过每人月15个功能点，对于瀑布式开发而言，这几乎不可能发生。

对于度量质量而言，最有效的测量值是“潜在缺陷”，该值使用功能点和“缺陷排除效率”进行了规范化。潜在缺陷是在需求、设计、代码、文档和不当的修复中发现的Bug总数。每个功能点有超过5个潜在缺陷则很糟糕；小于3个则相当不错。

Ken Schwaber写了一篇博文《敏捷价值》，探讨了如何度量IT投资创造的价值：

（……）价值定义为组织财务上的支出收益。在进行度量的时候，价值可以包含整个组织，也可以进行限制，比如限制到单个部门或生产线。无论如何，它必须包含受支出影响的方方面面。

组织投资价值可以通过名为“敏捷指数（agility index）”的单一指标进行度量，该指标是在“敏捷路径框架（agility path framework）”中定义的。该指标结合了几个指标的结果：

运营指标：度量组织效率。这些指标严重倾向于IT，即组织内的软件开发和部署。它们包括流程、生产周期、稳定性、质量、使用率和发布周期。业务运营效率没有包含在这些测量值中，而是作为Kotter International（John Kotter） Accelerate！项目的一部分在2014年加以处理。

组织指标：度量投资效率对市场的影响和组织累计获得的价值。这些指标包括员工人均收入、客户和员工满意度以及产品/系统成本比率。

正如Ken所述，人们可以在Scrum冲刺结束的时候度量它交付的价值：

在敏捷项目中，每个冲刺或迭代都是一个完整的项目。它有需求、预算和截止日期。最后，它有一整套的软件功能。根据它所完成的工作，另一个项目可以或者不可以启动，并向刚刚完成的功能中添加更多的功能。每个冲刺单独度量。

Cutter的博文《人们太容易用错误的方式度量敏捷的价值》探讨了敏捷价值度量的必要性。关于计算什么以及需要避免的陷阱，Tom Grant提供了一些指导方针：

• “敏捷方法的价值不同于敏捷团队生产的软件的价值”：在组织里，评估故事的业务价值无助于保证敏捷实施的投资。
• “业务价值存在于业务活动这一层次上”：不是故事有业务价值，而是业务活动使用交付的软件。Tom写道“价值存在于史诗和主题这一层次上”。
• “投资组合必须在计算价值方面发挥一些作用”：已交付软件的业务价值部分还与它不包含的功能有关。
• “价值是一种互补的度量”：度量价值需要同时包含技术的生产者和消费者。
• “没有人相信可以精确地度量，但它们依然有用”：虽然无法精确地计算价值，但人们仍然想有一个数值可以拿来讨论。
• “ROI计算结果可以大到难以置信”：当看到很大的数值时，人们可能会怀疑，但它们可能是正确的。
• “对于回报的投资可能比投资回报率更重要”：在敏捷上的投资不足可能会导致实施失败。
• “除了ROI之外，还有许多其它的指标”：在实施敏捷的业务场景中，其它指标也可能会有用。