大多数敏捷团队心中都有一个隐含的假设：“价值”与团队的“速度”直接成正比。这种看法在某些情况下也许是正确的，但是在大多数时候，团队的速度并不能反映他们真正交付的价值。

　　Ryan Shriver认为：价值是对已交付益处的度量，要由利益干系人决定。而另一方面，速度是团队在一个迭代中完成的故事点数的累加。这些故事点数是否全部都有价值，还是个问题。在Ryan看来，开发团队应该提出下面的问题：

　　回答这个问题：对于给你的项目、产品、服务提供经费的人来说，他们觉得什么最重要？是他们从解决方案中得到的好处吗？比如增加收入、市场份额，或是提升运营效率（我们将这些称为业务价值）？
 
　　还是开发团队的估算准确率、或者速度？

　　与之类似，Mike Cottmeyer提出价值和速度之间没有明确的关联关系。也许团队能够以很快的速度开发一个又一个的功能，并因此得到很大的速度值。然而，如果销售团队无法售出产品，或者业务部门无法使用，那么开发团队基本上就没有提升什么价值。他还指出：复杂产品的价值将会取决于整个链条中所有团队增加的价值。Mike认为：

　　假如目前有四个团队共同开发一个要推向市场的产品套件。团队A、B、C的速度都令人高兴，但是团队D的人都还没到齐。Team D ultimately delays the release… and the overall product is late to market. 最终团队D导致了产品发布延迟，整个产品也错过了最好的上市时间。与此同时，竞争对手刚刚发布了他们产品的最新版本，而你们的产品就不怎么样了。

　　这样看来，如何衡量团队A、B、C对于你的产品的整体价值起到多少帮助作用呢？再次强调：速度很高，不等于价值很高。

　　那么，如果速度有缺陷，衡量生产力的最佳度量方式是什么？

　　Kai Gilb建议设立产品价值负责人角色。他阐述了如何在Scrum中将项目干系人和产品价值结合起来，以衡量价值。这里，产品负责人在项目干系人和产品价值的层面上作出规划，设定优先级，并跟踪结果。

　　Ryan Shriver列举了其他衡量价值的技巧。

　　James Shore推荐使用一种有趣的方式来衡量生产力。这被称为价值速度。James认为：

　　关键之处在于：不要让你的业务专家在交付之后度量业务价值（这样很难！），先让他们估算。每个故事（或者功能）在列入开发日程之前先进行估算。在每个迭代结束时，将所完成的每个故事的业务价值估算汇总起来。这就是你的“价值速度”。它类似于传统的速度，但是是基于客户对于业务价值的估算，而不是程序员对投入成本的估算。

　　这样看来，速度并不能总是反应团队的真实生产力。关键在于度量交付的价值，并作出努力，争取在每个迭代中都能交付更多的价值，而不是更快的速度。