Scrum 事件开完却没有形成可用决定，常见表现是站会同步完信息、评审演示完增量、回顾列完改进项，下一轮工作仍按原样推进。恢复衔接的关键在于逐事件重设目标、输入输出与参与角色，让每项产出都有明确的消费者和承接动作，再用一轮事件验证产出是否真正驱动了决策。
要点总览（TL;DR）
- 断点判断：用“事件—产出—消费者—决策”四列核对，区分单个事件失效与事件链脱节。
- 原因排查：按影响面从大到小验证角色缺位、输入缺失、承接缺失、目标模糊四条假设，每条假设需有可指认的记录证据。
- 处置顺序：从断点最严重的事件开始，逐事件重设目标句、输入清单与输出模板，明确决策人到场或授权，一轮只改一个事件。
- 恢复验证：下一事件引用上一事件产出、决定有负责人和截止时间、待决项按期关闭，连续两轮成立可认为衔接恢复。
- 复发预防：固定输出模板、在议程中保留上次决定跟进项、回顾只保留可验证的改进项。
先确认断点：哪些事件产出没有进入决策
事件产出支撑不了决策，先要分清是单个事件失效，还是整条事件链脱节。判断依据可以统一为三个观察点：产出是否被下一事件引用、是否形成明确决定、是否有负责人承接。三项都缺失，说明该事件只完成了信息传递；三项在多个事件上连续缺失，说明事件之间已经失去衔接。
Scrum 五类事件各自应产出可被消费的决策物，可以按下表逐一核对。
| 事件 | 应产出的决策物 | 主要消费者 | 应形成的决定 |
|---|---|---|---|
| Sprint 规划 | Sprint 目标与 Sprint Backlog | 开发团队、每日站会 | 本轮迭代做什么、为什么做、如何开始 |
| 每日站会 | 当日可执行的调整 | 开发团队当日工作 | 障碍由谁处理、工作如何重新分配 |
| Sprint 评审 | 可交付增量及反馈 | 产品负责人、下一轮规划 | Backlog 如何调整、哪些事项进入下一轮 |
| Sprint 回顾 | 改进项及负责人 | 下一轮规划与执行 | 下个 Sprint 采纳哪些改进、由谁跟进 |
| Sprint 本身 | 符合完成定义的增量 | 评审、干系人 | 增量是否可交付、是否发布 |
核对时把每个事件的产出填进“事件—产出—消费者—决策”四列，再标注断点位置。局部断点表现为某个事件有产出但无结论，例如评审演示结束没有形成 Backlog 调整；链条断点表现为产出从未进入下游，例如回顾改进项连续几个 Sprint 都没有出现在规划议程中。两类断点的处置范围不同，局部断点修单个事件，链条断点需要同时检查相邻事件的输入输出约定。
原因排查：产出为何支撑不了决策
断点定位之后，原因仍需验证。以下四条假设覆盖多数情况，排查时按影响面从大到小排序：角色缺位影响整条事件链，优先核查；其次是输入缺失和产出无承接；事件目标模糊通常影响单个事件，放在后面处理。
| 假设 | 成立所需证据 | 排除依据 |
|---|---|---|
| 事件目标模糊，产出停留在信息汇报 | 回看最近几次事件记录，产出只有进度描述，没有待选项、建议方案或取舍理由 | 产出中已有明确选项和建议，只是未被采纳 |
| 输入缺失，事件开始前没有可用材料 | 事件前 Backlog 未梳理、增量不可演示、数据未准备，参与者现场才第一次看到内容 | 输入齐备，讨论仍无法收敛 |
| 角色缺位，决策人未参与或无权拍板 | 核对参与者名单与决策权限，关键决定长期由缺席者事后否决或无人拍板 | 决策人到场且有权，决定仍无法形成 |
| 产出无承接机制，决定没有下落 | 追踪上次决定，找不到对应工作项、负责人或下一事件议程条目 | 决定已登记并有负责人跟进 |
排查时先取证据再下结论。例如怀疑角色缺位，不要凭印象判断，直接调出最近三次评审的参与者与最终决定记录，看决定是否由到场者作出。怀疑目标模糊，就抽取两次事件产出，检查其中是否包含“选 A 还是选 B”这类待决结构。每条假设成立或排除，都应有可指认的记录，避免把一次会议体验当成系统原因。
多条假设同时成立时，先处理影响面最大的一条。角色缺位往往会让其他调整失效：即使目标写清楚、模板给到位，无人拍板仍然形不成决定。输入缺失和承接缺失可以并行修复，因为它们分别位于事件的两端，互不干扰。
恢复衔接的处置步骤：重设目标、输入输出与角色
处置从断点最严重的事件开始，按“目标—输入输出—角色—承接”四步逐事件调整，一轮只改一个事件，观察效果后再动下一个。
第一步，为每个事件写一句目标。目标句采用“本次事件结束时必须形成什么决定”的句式。例如评审的目标句写成“确认本增量是否可交付，并决定下一轮 Backlog 的增删项”；回顾写成“确定下个 Sprint 采纳的两项改进及负责人”。目标句写不出决定，说明该事件当前只承担汇报功能，需要先补决策内容。
第二步，定义输入清单与输出模板。输入清单在事件开始前核对，例如规划前确认 Backlog 已排序、上一轮增量状态已知；评审前确认增量可演示、验收标准明确。输出模板至少包含四栏：结论、待决项、负责人、截止时间。结论写已定事项，待决项写本次未决、需要谁在何时给出答案的事项。模板的作用是让“没有结论”变成可见状态，而不是让会议在模糊中结束。
第三步，明确产出消费者与承接动作。每个事件的产出指定一个下游消费者，并约定承接形式：规划产出的 Sprint Backlog 进入看板成为工作项；评审结论转为 Backlog 调整项；回顾改进项登记为工作项或下一轮规划议程条目。承接动作要落到具体载体上，口头承诺不算完成承接。
第四步，调整参与角色。决策人必须到场，无法到场时指定有明确授权的代表，授权范围写清楚。记录与分发指定到人，事件结束后当日内把产出同步给消费者。角色调整涉及团队基本约定时，先在团队内确认再执行，避免把权限问题当成流程问题处理。
处置顺序与停止点同样重要。先修链条断点中最严重的一环，例如回顾改进项从未进入规划，就先在规划议程中固定加入上次改进项的跟进环节。完成一个事件的调整后，至少观察一轮完整事件周期，确认产出被消费再处理下一个事件。同时改动全部事件会让效果无法归因，也容易让团队把调整当成一次性运动。
事件产出和决定需要落到可追踪的载体上，衔接才有依据。在 ONES 中，产品负责人可以按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；每日站会可以借助敏捷看板对齐迭代进度与风险；迭代回顾可以结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量和成本偏差。回顾形成的经验可以用 ONES Wiki 沉淀为团队知识库，Wiki 支持文档关联任务并插入工作项列表，便于把改进项与具体工作项对应起来。这些能力承载的是产出登记与跟进，事件目标与决策规则仍需团队自己定义。
验证恢复效果与防止再次脱节
衔接是否恢复，用三个可核验的观察点判断：下一事件是否引用了上一事件的产出；每项决定是否有负责人和截止时间；待决项是否在约定时间内关闭。三项在连续两轮事件中稳定成立，可以认为衔接已恢复；只有产出被存档、下一事件议程中没有出现，说明承接环节仍未打通。
验证放在下一次事件中进行，做一次简短回看：上次评审的结论是否体现在本轮规划中，上次回顾的改进项是否出现在本轮执行里。回看只核对引用与关闭情况，不重新讨论内容，避免验证本身变成新的长会。
复发预防采用低成本机制：固定输出模板，让每次事件产出结构一致；在事件议程中保留上次决定的跟进项，作为固定开头；回顾只保留可验证的改进项，每条改进项写明观察指标和检查时间。改进项无法验证时，宁可不列入，也不要用“加强沟通”这类无法核对的表述填充清单。
调整事件形式之前，先确认团队对 Scrum 角色的基本约定是否清晰。如果决策权限本身没有明确，缩短会议、更换模板都只能缓解表面症状。此时应优先解决角色与授权问题，再谈事件流程的优化，避免用流程改动掩盖目标缺失或权限不清。
常见问题
团队在回顾会上列了改进项，但下个 Sprint 完全没有执行，应该先改回顾还是先改规划？
先改规划。回顾改进项没有进入下个 Sprint，说明承接环节断在规划议程上。可以在规划会议开头固定加入“上次回顾改进项跟进”环节，逐条确认采纳、推迟或放弃，并指定负责人。回顾本身的产出格式可以暂时不动，等规划能稳定承接后再优化回顾的改进项写法。
决策人经常无法参加评审，授权代表也不明确，事件产出还能支撑决策吗？
授权不明确时，评审产出容易停留在信息同步层面。恢复衔接的做法是先明确授权范围：决策人书面指定代表，写清代表可以决定哪些事项、哪些必须回传决策人。评审输出模板中增加“待决策人确认”栏，把需要回传的事项单独列出并约定回复时限。这样即使决策人缺席，产出仍能进入决策流程，而不是停在会议记录里。
调整事件目标后，团队觉得会议变长了，怎么判断调整是否有效？
用产出是否被消费来判断，而不是用会议时长。有效的标志是下一事件引用了本次产出、决定有负责人和截止时间、待决项按期关闭。如果会议变长但产出仍未被下游引用，说明目标句没有落到决策上，需要检查目标句是否写成了“讨论什么”而不是“结束时必须形成什么决定”。会议时长可以在衔接稳定后再优化。
多个事件同时出问题，可以一次性全部调整吗？
不建议。同时调整全部事件会让效果无法归因，团队也难以判断哪项改动起了作用。处置顺序按影响面从大到小：先修链条断点中最严重的一环，观察一轮完整事件周期，确认产出被消费后再处理下一个事件。角色缺位通常影响整条链，应优先核查和修复。
ONES 能帮助记录事件产出和跟踪决定吗？
可以承载产出登记与跟进。产品负责人可以按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；每日站会可以借助敏捷看板对齐迭代进度与风险；迭代回顾可以结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量和成本偏差。回顾形成的经验可以用 ONES Wiki 沉淀为团队知识库，Wiki 支持文档关联任务并插入工作项列表，便于把改进项与具体工作项对应起来。事件目标与决策规则仍需团队自己定义。
