不靠数故事点来衡量敏捷：一个团队转向循证管理
一家服务公司的软件团队，自以为已经把敏捷搞明白了。所有 Scrum 事件都开，看板整整齐齐，速率也一个季度比一个季度往上爬。当一位新上任的总监抛出一个直白的问题——「我们到底是在交付价值这件事上变得更强了，还是只是更忙了？」——会议室一下子安静下来。他们能报出完成了多少故事点，却说不出客户是否因此过得更好。这道鸿沟，正是来自 scrum.org 的循证管理框架要去弥合的。
时机让这个问题更显尖锐。那是2021年初，团队已远程办公一年，随着客户适应混合办公的世界，对其产品的需求也发生了转移。产出很稳定，却没人说得清这些产出对掏钱的人是否还重要。事实证明，速率衡量的是团队有多忙，而不是它的成果。
循证管理衡量什么
循证管理（EBM）帮助组织通过衡量成果而非活动来改进，并利用这些度量去开展朝向目标的小型实验。它把度量归入四个领域，称为关键价值领域。我们案例中的团队几乎完全活在其中一个角落里，对其余的视而不见。
当前价值——产品此刻为客户和用户交付的价值。
未实现价值——若满足更多需求，未来可能获取的价值。
上市时间——团队交付新能力或新认知的速度。
创新能力——团队有多少余力去交付新价值，而不是在与老问题缠斗。
这个团队做了哪些不同的事
他们没有把速率扔掉，而是把它放回应有的位置，并加入了能说明成果的度量。这一转变与其说在于新的仪表盘，不如说在于提出更好的问题，并愿意听取令人不安的答案。
从价值目标出发。 他们不再追求「提高速率」，而是设定了一个与当前价值挂钩的目标：提高每周完成一项核心任务的活跃客户的比例。
诚实地衡量上市时间。 他们计量一个想法抵达客户需要多久，发现吞掉大部分日程的是审批，而不是编码。
审视创新能力。 他们估算了维护旧功能与创造新价值各自投入的精力，并为留给新事物的份额之少而感到不安。
做实验，而非下命令。 每个冲刺都针对某项度量试验一个小改动，从而了解到底什么真正撬动了成果，而不是为此争论不休。
发生了什么变化，又为何能持续
两个季度内，评审会上的对话变了。干系人不再问完成了多少点数，而开始问价值目标有没有在移动。团队砍掉了一个被 EBM 暴露出来的缓慢审批环节，这对上市时间的改善，超过任何代码改动所能带来的。又因为如今每个决定都与一项可衡量的成果挂钩，争论变短了——拍板的是数据，而不是嗓门最大的人。
更深一层的教训是：敏捷不是你照本宣科的一套仪式，而是交付价值、并在交付中不断改进的、得到证明的能力。EBM 不会把答案直接递给你，它给你诚实的度量和实验的习惯，二者合在一起，把「我们觉得自己挺敏捷」变成「证据在此」。
如果你的团队很忙，却不确定是否在交付价值，XNM 的项目群与项目交付咨询服务 可以帮你为自己的敏捷找到证据支撑。