迭代规划会开完，Sprint Backlog 仍可能停留在“会议记录”状态：条目描述只有一句话，负责人不清楚从哪一步开始；一个条目横跨多天，进度只能靠口头同步；依赖没有标注，执行到一半才发现要等外部输入。本文给出一套会后可用的粒度标准、筛选与拆解步骤、角色分工和巡检规则，帮助团队把 Sprint Backlog 维持在可执行状态。条目拆分、状态流转和巡检记录可以在 ONES 工作项中承载，便于会后持续维护。
要点总览（TL;DR）
- 规划会后先统一可执行粒度的判断口径：从工作量、完成标志、依赖、验收方式四个维度检查条目，并补齐进入执行前的最小信息集。
- 整理按五步推进：按迭代目标筛选候选条目、拆到可执行大小、补齐输入动作输出与完成标志、标注依赖与阻塞、形成条目清单与拆解记录。
- 产品负责人确认迭代目标与验收标准，迭代负责人组织整理与巡检，开发人员参与拆分并反馈阻塞，交接产物随条目同步更新。
- 粒度靠持续巡检维持：在站会前后、迭代中期和条目领取前检查，条目过大或阻塞时触发拆分重估，新增条目需经必要性与容量确认。
- 迭代结束时未完成工作重新评估后再决定去向，不做默认结转，每条未完成工作都应有明确处理结论和理由。
规划会后先定粒度标准：什么算可执行
可执行粒度指一个条目在迭代执行期间能被单独领取、单独推进、单独判断是否完成。规划会结束后，团队先用统一口径检查每个条目，再决定保留、拆分或退回。判断标准可以从四个维度展开。
四个判断维度
| 维度 | 可执行的表现 | 需要调整的信号 |
|---|---|---|
| 工作量 | 一名开发人员一天内能推进并交付一个可验证结果；需要多人协作的条目已拆出并行部分 | 条目连续占用两天以上仍无中间产出；多人同时等待同一条目完成 |
| 完成标志 | 写清交付物是什么、由谁验收、满足什么条件算完成 | 完成标志只有“开发完成”“处理一下”这类无法核对的表述 |
| 依赖 | 前置输入、外部接口、其他条目的先后关系已标注，并写明提供方与时间 | 执行前才发现需要等待设计稿、接口或数据 |
| 验收方式 | 明确由产品负责人、测试人员或指定角色按什么方式确认结果 | 验收人缺位，或验收标准与条目描述分离 |
工作量维度需要结合团队实际调整。对于探索性任务，一天内可能只产出验证结论而非完整功能，此时完成标志应写成“完成某方案验证并给出结论”，而不是强行套用功能交付的标准。
用迭代目标做筛选器
规划会后整理条目时，先确认本迭代目标，再逐条检查条目与目标的对应关系。每个条目应能回答“支撑哪个迭代目标、以什么方式支撑”。与目标无直接关系但必须处理的事项，应单独标注来源和必要性，由产品负责人决定是否占用本迭代容量。对应关系不清的条目，优先退回产品待办列表，而不是留在 Sprint Backlog 中等待执行。
进入执行前的最小信息集
条目在进入执行前至少具备以下信息，缺一项就不应被领取：
- 条目名称与一句话说明，能看出交付什么；
- 所属迭代目标及对应关系；
- 负责人或领取人；
- 输入条件：需要的设计、接口、数据、环境或前置条目；
- 完成标志与验收方式；
- 已识别的依赖与阻塞，以及处理方式；
- 工作量估计或相对大小。
这套最小信息集既是拆解目标，也是会后巡检的检查依据。团队可以把它固化为工作项的必填字段，减少口头补充。
从迭代目标到Sprint Backlog条目的筛选与拆解步骤
规划会后的整理可以按五步推进，每一步都有明确输入和输出，避免整理工作变成反复讨论。
第一步：按迭代目标筛选候选条目
输入是规划会形成的候选条目清单和迭代目标。动作是逐条判断条目与目标的支撑关系，并标注取舍理由：保留、拆分后保留、退回待办、延后。输出是一份带取舍理由的候选清单。取舍理由要具体，例如“支撑目标中的结算流程打通，但依赖支付接口联调，需拆出前置部分”，而不是简单写“重要”或“不急”。
第二步：把条目拆到可执行大小
拆分依据优先选择能产生独立可验证结果的方向：
- 按流程步骤拆：把端到端流程拆成可分别验证的环节；
- 按数据或规则分支拆：不同业务规则、不同输入类型分别成条；
- 按界面与后台拆：需要不同角色推进的部分分开；
- 按前置条件拆：把准备环境、接口联调、数据准备单独成条；
- 按验收场景拆：每个可独立验收的场景对应一个条目。
拆分后检查每个子条目是否满足一天内可推进、有独立完成标志。拆分记录应保留原条目与子条目的对应关系，便于回溯为什么这样拆。
第三步：补齐输入、动作、输出与完成标志
对每个保留条目补写四类信息：输入是开始前必须具备的条件；动作是执行者要完成的主要工作；输出是交付物或状态变化；完成标志是验收人可核对的判断依据。以“订单导出功能”为例，输入为已确认的导出字段清单和测试数据，动作为实现导出并覆盖指定字段，输出为可下载的导出文件，完成标志为按字段清单核对无误并通过验收人确认。
第四步：识别依赖与阻塞并标注处理方式
逐条检查是否存在前置条目、外部团队交付、环境或数据依赖。对每项依赖标注提供方、需要时间和当前状态，并写明处理方式：等待、并行准备、调整顺序或缩小范围。无法在迭代内解决的依赖，应作为风险记录并同步给产品负责人，而不是留到执行中临时协调。
第五步：形成整理后的条目清单与拆解记录
输出包括整理后的 Sprint Backlog 条目清单、拆解前后对照、依赖清单和取舍记录。清单确认后，条目才进入可领取状态。整理结果可以在 ONES 工作项中按迭代归集，拆分关系通过父子工作项保留，依赖和阻塞用字段或关联关系标注，方便会后巡检时直接核对。
角色分工与各环节交付物
维持粒度需要产品负责人、Scrum Master 或迭代负责人、开发人员三方配合，各自对不同的产物负责。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 确认迭代目标；判断条目与目标的对应关系；决定退回、延后或调整范围；确认验收标准 | 迭代目标说明、取舍理由、验收标准 |
| Scrum Master / 迭代负责人 | 组织会后整理与粒度巡检；维护拆解记录和依赖清单；跟踪阻塞处理；主持变更判断 | 整理后的条目清单、依赖与阻塞清单、巡检记录、变更记录 |
| 开发人员 | 参与拆分并评估工作量；补写输入、动作、输出与完成标志中的技术部分；领取条目并反馈阻塞 | 条目拆解建议、工作量估计、执行中的阻塞反馈 |
条目拆分由开发人员提出方案，产品负责人确认业务范围和验收标准，迭代负责人确认拆分后仍支撑迭代目标且依赖已标注。验收标准的最终确认权在产品负责人；技术实现方式的确认权在开发人员。交接产物应随条目一起更新，避免拆分结论只停留在会议口头共识中。
会后粒度巡检与变更规则
规划会后的整理是一次性动作，粒度能否保持取决于持续巡检和明确的变更规则。
巡检时点与检查项
建议在每日站会前后、迭代中期和条目领取前三个时点做粒度检查。检查项包括：条目是否仍能在一天内推进并交付可验证结果；完成标志是否仍然清晰；依赖是否已解除或仍在等待；是否有条目连续多日没有状态变化。迭代中期做一次完整巡检，重点看剩余条目是否仍然匹配迭代目标。
拆分与重估的触发条件
出现以下情况时触发拆分或重估：条目执行超过预期时间仍无中间产出；发现新的依赖或阻塞导致无法继续；验收标准发生变化使原条目范围扩大；开发人员反馈工作量估计明显偏差。触发后由迭代负责人组织简短评估，决定拆出新条目、调整完成标志还是缩小范围，并同步更新拆解记录。
执行中新增条目的准入规则
迭代执行期间新增条目需要满足三个条件：与当前迭代目标直接相关，或属于必须处理的紧急事项；具备最小信息集；明确由谁腾出容量承接。新增条目由产品负责人确认必要性，迭代负责人确认容量影响，双方确认后写入 Sprint Backlog 并记录来源。未满足条件的条目进入待办列表，不直接插入当前迭代。
未完成工作的处理方式
迭代结束时未完成的条目不做默认结转。团队先重新评估：条目是否仍然支撑下一迭代目标；拆分是否合理，是否需要进一步拆小；阻塞是否已解除；优先级是否发生变化。评估后分别处理为重新拆解后纳入下一迭代、退回产品待办列表、调整范围后关闭或取消。每条未完成工作都应有明确去向和理由，避免把上一迭代的模糊条目原样带入下一迭代。
巡检记录和变更记录可以在 ONES 工作项的状态流转与迭代视图中留存，使拆分、阻塞和未完成去向有据可查，减少会后靠记忆维护粒度的情况。
示例：一个迭代目标下的条目整理过程
以下为演示情景，用于说明整理过程，不代表真实项目数据。
示例迭代目标与候选条目
某迭代目标为“完成客户信息批量导入并支持导入结果查询”。规划会后的候选条目包括：客户信息批量导入、导入结果查询、导入模板下载、导入失败数据修正。其中“客户信息批量导入”描述为“实现批量导入功能”，没有拆分，也没有写完成标志。
拆解前后的条目对比
| 对比项 | 拆解前 | 拆解后 |
|---|---|---|
| 条目范围 | 一个条目覆盖上传、校验、入库、结果反馈 | 拆为上传与格式校验、数据入库、导入结果生成三个子条目 |
| 完成标志 | “导入功能完成” | 上传与格式校验：错误格式文件被拦截并提示原因；数据入库：指定测试数据全部入库且字段核对一致；结果生成：可查询成功与失败条数及失败原因 |
| 依赖 | 未标注 | 数据入库依赖客户主数据字段确认；结果查询依赖导入结果表结构 |
| 验收方式 | 未写明 | 产品负责人按测试数据核对导入结果，开发人员提供核对记录 |
拆解后，“导入模板下载”因不直接支撑迭代目标，经产品负责人确认退回待办列表；“导入失败数据修正”依赖导入结果生成，标注为后续条目并写明前置关系。
会后巡检发现的问题与处理
迭代中期巡检发现“数据入库”条目连续两天没有状态变化，开发人员反馈客户主数据字段尚未确认。迭代负责人将该阻塞记录为依赖项，产品负责人当天确认字段清单，条目恢复推进。同时发现“导入结果生成”范围扩大，新增了按失败原因分类统计的要求，团队将其拆出一个独立条目，并调整了完成标志。迭代结束时，“导入失败数据修正”未完成，团队评估后认为它仍支撑下一迭代目标，但需要先拆出失败原因分类的展示部分，于是重新拆解后纳入下一迭代，而不是原样结转。
完成检查：粒度是否守住的核对项
迭代执行期间和迭代结束前，可以用以下清单逐项核对 Sprint Backlog 是否保持可执行粒度。
| 检查类别 | 核对项 | 通过标准 |
|---|---|---|
| 目标对应 | 每个条目是否写明支撑的迭代目标；是否存在与目标无关且未经确认的条目 | 条目均能说明对应关系；例外条目有产品负责人确认记录 |
| 条目大小 | 条目是否能在一天内推进并交付可验证结果；是否存在连续多日无中间产出的条目 | 超长条目已拆分或已说明原因并安排中间检查点 |
| 完成标志 | 每个条目是否有可核对的完成标志和验收方式；验收人是否明确 | 完成标志具体到交付物或状态，验收人已指定 |
| 依赖与阻塞 | 依赖是否标注提供方和时间；阻塞是否有处理方式和负责人 | 无未标注依赖；阻塞项有跟进记录 |
| 新增条目 | 执行中新增条目是否经过必要性和容量确认 | 新增条目有来源记录和确认人 |
| 未完成工作 | 未完成条目是否经过重新评估并有明确去向 | 每条未完成工作有处理结论和理由，无默认结转 |
清单可以在迭代中期巡检和迭代结束回顾时各执行一次。发现不通过的条目，当场明确处理人和处理时点，并把结论更新到条目和拆解记录中。粒度标准、拆解步骤、角色分工和巡检规则形成闭环后，Sprint Backlog 才能在规划会结束后持续保持可执行状态。
常见问题
条目拆到多小才算合适？探索性任务也要按一天来拆吗？
功能类条目通常以“一名开发人员一天内能推进并交付一个可验证结果”为参考。探索性任务不必强行套用功能交付的标准，可以把完成标志写成“完成某方案验证并给出结论”，只要这个结论能被单独核对，条目就具备可执行粒度。关键是条目能被单独领取、单独推进、单独判断是否完成，而不是机械按天数切分。
规划会后整理条目，产品负责人和迭代负责人意见不一致怎么办？
先区分分歧属于哪一类。涉及业务范围、优先级和验收标准的，由产品负责人确认；涉及拆分后是否仍支撑迭代目标、依赖是否已标注、容量是否够用的，由迭代负责人确认。两边判断冲突时，把条目退回待办列表并记录分歧理由，等条件明确后再纳入，避免带着未决问题进入执行。
迭代执行到一半，发现某个条目比预估大很多，应该直接拆还是先做完？
出现执行超过预期时间仍无中间产出、发现新依赖或验收标准变化导致范围扩大时，就应触发拆分或重估，不必等到做完。由迭代负责人组织简短评估，决定拆出新条目、调整完成标志还是缩小范围，并同步更新拆解记录和依赖清单。继续硬推会让进度失去可见性，也会挤占其他条目的容量。
迭代结束时没做完的条目，什么情况下可以带进下一迭代？
带进下一迭代的前提是重新评估通过：条目仍支撑下一迭代目标、拆分合理、阻塞已解除、优先级没有变化。评估后可以重新拆解再纳入，也可以退回产品待办列表或调整范围后关闭。每条未完成工作都要写明去向和理由，原样结转会让上一迭代的模糊条目继续占用下一迭代容量。
团队规模小、没有专职 Scrum Master，巡检由谁来做？
可以由迭代负责人或团队内指定的协调角色承担巡检组织工作，检查项和触发条件保持不变。小团队可以把巡检压缩到每日站会前后和迭代中期两个时点，重点看条目是否仍能在一天内推进、依赖是否解除、是否有条目连续多日无状态变化。角色合并时，产品负责人确认验收标准和范围、开发人员反馈阻塞的分工仍需保留。
