在敏捷2016大会上，Johanna Rothman敏捷项目管理的度量指标发表了演讲。她首先确认了项目团队当前在结果度量方面所面临的问题：
　　1. 度量什么？
　　2. 什么可以被我们度量？
　　3. 什么指标有用？
　　Johanna解释说，管理层看到的是全局，而团队看到的是自己团队的状况。项目全部都要看。她介绍了敏捷团队如何使用指标帮助团队实现自组织和自管理；不过，那些数据对管理层而言没有意义。
　　Johanna还解释说，你可能得根据项目情况改变并选择合适的指标。
　　她还提到，如今的度量指标不断变化，这是有历史原因的，是无法保证团队可以连续不断地交付价值。为此，经常要求使用预测性度量指标，而不是经验性度量指标。
　　接下来，Johanna列举了真正关心的内容，如客户赢取率、客户保持率、营收增长率、客户体验和接触点。对于SaaS公司而言，客户体验非常关键，因为如果无法提供良好的客户体验，则企业客户可以选择其他的提供商。
　　她举例说明了指标的转换模式，下面是其中的一部分，比较了预测性指标和经验性指标：

　　Johanna还比较详细地描述了需要重点度量的方面。
　　度量学习：学习有法度量吗？总是寻求获得小段代码的反馈，并且问问自己，“我们还需要进一步学习吗？”我们通过学习获得动力。
　　度量趋势：我们造成的缺陷多过修复的缺陷吗？缺陷比以前多了吗？关键是随着时间推移的趋势数据。快照无法提供足够的信息。
　　度量已完成的特性：项目始于长篇故事/主题，听上去像特性，但实际上模糊不清，无法确定交付什么。不要把这些作为特性。从为客户提供价值的角度出发，度量更具体的特性。
　　度量产品待办事项列表燃尽图：部分地回答“我们处于什么阶段？”，展示特性范围何时扩大了以及特性的整体进展。数一下每个特性集的故事数量，并用它作为度量数据。
　　度量你需要增加什么以及需要减少什么：减少WIP、减少多任务。增加可以工作的软件，这是用户关心的；增加发布的用户满意度。
　　度量成本：运转率营收（美元），团队每月的成本是多少，我们愿意为我们每月取得的成果支付这些成本吗？（从客户的角度看发布的成果和有价值的软件。）
　　度量发布：发布频率——从构建到发布需要多长时间？将构建时间缩短到几个小时！我们的构建时间是延长了，还是缩短了？不应该延长吧？周转时间——一项特性从准备到发布需要多长时间？
　　度量产品指标：创建场景或性能场景。人们需要登入、传输文件、支付，等等。这些任务的性能属性如何？性能、可靠性……。产品性能指标：这些可以是发布标准的作用。自上次发布至今，我们有改善吗？
　　度量质量指标：客户反馈和满意度。
　　你多久一次从客户那里获得反馈？障碍报告——有人会有障碍。决策需要多长时间？项目之外的事情影响了我们完成工作的能力吗？
　　后，她列举了自己看过的常见的度量陷阱：
　　◆ 永远不要度量个体或团队的生产力；
　　◆ 永远不要比较相邻的人；
　　◆ 永远不要比较团队。
　　特邀编辑Angela Wick是一名敏捷教练兼培训师。同时，她还是BA-Squared，LLC的创始人兼首席执行官。那是一家培训和咨询公司，帮助组织实现需求实践的现代化。她帮助传统、敏捷及混合团队发展所需的技能，构建正确的解决方案，为组织提供预期的价值。