聚焦价值而非产出：一个Scrum团队的故事

在Scrum中，每个Sprint的目的是向客户和组织交付价值。速率——每个Sprint完成的故事点数——是一个有用的内部规划工具，但它不是价值的衡量标准。一个具有高速率但在构建错误事物、或为无法访问的用户构建正确事物的团队，并没有在交付价值。以下场景描述了一种比大多数Scrum团队意识到的更为常见的模式。

场景：一个数字服务团队

一个省级政府机构的Scrum团队正在开发一个在线许可证申请服务。该团队每个Sprint的速率为42个故事点。他们六个月来每个Sprint都有交付，共完成1008个故事点。2022年4月，机构进行用户研究，发现78%的许可证申请人仍在使用纸质表格而非在线服务。尝试过在线服务的22%中，60%在完成申请前放弃了。在线服务在技术上已完全正常运行了四个月。

出了什么问题

• Sprint目标是功能交付目标，而非成果目标。每个Sprint目标的措辞类似"完成支付集成模块"或"实施文档上传功能"。没有一个Sprint目标涉及用户采用率、完成率或从纸质到在线的过渡。

• 产品Backlog是功能列表，而非经过优先排序的价值交付计划。产品负责人按技术依赖性和估算复杂性对Backlog排序，而非按预期用户影响排序。解决采用主要障碍——早期用户测试发现的混乱导航结构——的功能被降低优先级，因为它们是"用户体验工作"而非"功能交付"。

• 团队与使用数据没有连接。团队中没有人跟踪有多少用户在尝试该服务、有多少人在完成它，或他们在哪里放弃。完成定义包含技术测试，但不包含实际环境中的任何可访问性或可用性度量。

• 产品负责人没有来自真实用户的反馈回路。Sprint评审由内部利益相关者参加，而非将要使用该服务的申请人。内部利益相关者的反馈始终确认功能在技术上是正确的，而非它们是否满足用户需求。

他们做了什么改变

团队围绕基于成果的Sprint目标（目标采用率、完成率）进行重组，在完成定义中增加了使用分析工具，建立了月度用户访谈计划，并根据采用障碍重新构建了产品Backlog。在随后的三个Sprint中，速率从42下降到31个故事点——因为用户体验修复工作比功能交付更难预测。但完成率从40%提高到68%，纸质表格使用率下降了25个百分点。团队的产出减少了，而价值大幅增加了。

XNM协助公共部门组织建立以成果为中心的Scrum实践。欢迎联系XNM项目群与项目交付咨询团队，探讨贵数字项目的以价值为导向的敏捷交付。