把名存实亡的 Sprint 评审变成真正的工作对话
一家物流公司的产品团队——姑且称之为「货运可视化」小队——有一场人人私下都怵头的 Sprint 评审。每隔一个周四，开发人员就对着一屋子半心半意的干系人逐张翻看截图。人们迟到、关着摄像头、回着邮件。在 2022 年初动荡的供应环境中，业务方迫切需要为这款产品掌舵，然而这个唯一为掌舵而设的事件却沦为了表演。
Scrum Master 注意到了那个关键症状：反馈从不在评审当场出现。它总是几天后通过私下邮件姗姗来迟，而且往往与团队刚刚做出来的东西相矛盾。Sprint 评审在日历上存在着，却没有履行它的职责。
Sprint 评审的用途
《Scrum 指南》说得很清楚：Sprint 评审是一场工作会议，Scrum 团队与干系人在会上检视增量以及他们所处环境中发生的变化，然后就接下来该做什么展开协作。产品待办列表可以当场调整。它明确既不是一次状态汇报会，也不是一次单向演示。这支小队悄悄把这一切都颠倒了过来——他们在演示，而非检视，更谈不上协作。
两种误解推动了这种衰退。其一，他们以为评审的目的是证明 Sprint 目标已达成。其二，他们把干系人当作需要被告知的观众，而非其意见能重塑待办列表的伙伴。一旦看清这两个错误，补救之道便水到渠成。
这支小队做了哪些改变
先讲环境，而非讲产物。 产品负责人用五分钟讲述发生了哪些变化——某承运商的 API 改动、某新客户的业务量——让全场依据当下的现实、而非上个 Sprint 的假设来评判工作。
让干系人亲自使用增量。 不再是配着旁白的截图，而是真实用户亲手点击运行中的功能。手触产品所激发的真实反应，是幻灯片永远换不来的。
提一个尖锐的问题，然后住口。 「这会改变你处理延误货件的方式吗？」胜过「有什么反馈吗？」前者邀请一个决定，后者邀请一片沉默。
在会场当场编辑待办列表。 当一位干系人指出缺了一个异常情形时，产品负责人当场在屏幕上把它加入并排好序。人们看到自己的意见落了地，便会投入其中。
邀请对的人。 两位真正使用产品、积极投入的干系人，胜过十位旁观者。他们精简了名单，气氛随之高涨。
改变了什么，以及为何能持续
几个 Sprint 之内，评审不再是一场广播，而成了真正塑造下个 Sprint 优先级的地方。私下的邮件销声匿迹，因为已不再需要它们——真正要紧的对话如今就在会场里、在恰当的时间、与恰当的人之间发生。摄像头打开了。会议变短了，却做成了更多事。
这条经验不止适用于这一支团队：Sprint 评审失败，并非因为干系人天生冷漠，而是因为一场演示让他们无事可做。把一个真实的决定和一个运行中的产品交到他们手上，参与就不再是需要苦苦哀求的东西。
让 Scrum 事件真正发挥作用，往往正是交付悄然改善之处——XNM 的项目群与项目交付咨询 帮助团队把敏捷仪式转化为真正的决策节点。