围绕迭代目标制定Sprint Backlog执行计划，关键在三件事：迭代目标写得可检验，进入迭代的条目按目标筛得清楚，条目拆到一两天内能完成、能跟踪的粒度。本文按规划会前后的顺序，给出迭代目标句式、条目筛选清单、任务拆解字段表、角色分工表和迭代中检查规则，并说明这些记录如何用ONES承载。
要点总览（TL;DR）
- 迭代目标写成“对象+期望结果+检验方式”的句式，一个迭代聚焦一个主方向，目标才能作为条目筛选的依据。
- 条目按“直接支撑目标—必要依赖—容量可承载”三步筛选，附带项和非目标请求不进入本次迭代或严格限量。
- 任务拆到一到两天内可完成，每个任务写清输入、动作、输出、完成标志，并标注负责人、依赖和验收口径。
- 规划会后用每日同步和燃尽趋势检查粒度，出现连续停滞或阻塞未解除就当场重拆、替换或缩小范围。
- 迭代结束时未完成项逐条重新评估，仍支撑目标的回到产品Backlog参与下轮筛选，不默认结转。
先写出一条可检验的迭代目标
迭代目标是Sprint Backlog的筛选依据，写法上要能回答三个问题：这次迭代针对什么对象、期望得到什么结果、用什么方式确认结果达成。目标写得含糊，条目取舍就会变成凭感觉排序，规划会也容易开成需求逐条讨论会。
可以直接套用这个句式：本次迭代面向〔对象/用户场景〕，完成〔期望结果〕，以〔检验方式〕确认达成。例如“本次迭代面向新注册用户，完成手机号验证码登录流程上线，以测试环境全流程通过并完成灰度验证确认达成”。对象、结果、检验方式齐全，团队对“做完没有”才有共同判断。
目标粒度建议一个迭代聚焦一个方向。两週迭代里同时塞进登录改造、报表优化和性能治理三个方向，每个方向都只能分到少量条目，遇到阻塞时没有调整余地。目标数量收敛到一个，附带工作作为支撑项处理，能让条目筛选有明确的主线。
目标还要与产品Backlog的优先级衔接。产品负责人依据需求优先级把候选需求规划到对应迭代，再在迭代计划会议上与团队共同评审，这一步决定了目标候选范围。目标应当从当前优先级最高的需求簇中提炼，避免目标指向一批排在后面的需求，导致迭代内资源与优先级脱节。
目标写不清时的返工动作要具体：规划会开始前由产品负责人重写目标句式的三个空位；如果检验方式写不出来，说明结果本身不可观察，需要把目标缩小到可验证的范围；如果对象范围过大，先切出一个用户场景或一条业务链路作为本次迭代的对象。返工在会前完成，会上只做确认。
目标自检可以看四点：对象是否具体到场景或用户群；结果是否是一个可交付的状态而非“推进”“优化”这类动作词；检验方式是否能在迭代结束前执行；目标是否只有一个主方向。四项都通过，才进入条目筛选。
从迭代目标筛出Sprint Backlog条目
条目筛选按“直接支撑目标—必要依赖—容量可承载”的顺序判断，先定方向，再定数量。顺序颠倒容易出现先按容量装满、再回头找目标关联的情况，Sprint Backlog就退化成一张任务清单。
第一步区分直接支撑与附带项。直接支撑指该条目完成后，目标的检验方式能向前推进一步；附带项指顺路可以做、但与目标检验无直接关系的工作。直接支撑项优先进入，附带项原则上不进入本次迭代，确有必要的单独标注并控制数量。
第二步处理必要依赖。依赖分两类：目标达成绕不开的前置条件，例如接口联调所需的第三方字段、上线所需的配置变更，属于必要依赖，应进入Sprint Backlog并明确完成时点；与目标无直接关系、只是其他团队希望本次一并处理的请求，按非目标项处理，排到后续迭代或另行安排。
第三步用容量约束数量。参考团队近几个迭代的实际完成量作为容量上限，而不是按理想工时排满。条目总量留出一定余量应对评审、缺陷和协作等待，具体比例按团队历史波动情况确定。容量判断以团队为单位，个人层面只做初步分配，避免把计划做成精确到人的工时表。
条目进入前还需具备就绪条件：需求描述清楚、验收口径可判断、关键依赖方已确认、必要的设计输入已具备。验收口径缺失的条目先退回补充，不带着模糊标准进入迭代，否则拆解阶段会反复返工。
| 判断顺序 | 判断问题 | 处理动作 |
|---|---|---|
| 直接支撑 | 完成后能否推进目标的检验方式 | 进入Sprint Backlog，排在前面 |
| 必要依赖 | 目标达成是否绕不开 | 进入并标注完成时点与依赖方 |
| 附带项 | 与目标检验无直接关系 | 不进入或严格限量，单独标注 |
| 非目标请求 | 其他团队的顺路需求 | 排后续迭代或另行安排 |
| 容量校验 | 总量是否在历史完成量之内 | 超出则从附带项和低支撑项开始削减 |
把条目拆成可执行的计划粒度
条目拆解决定Sprint Backlog能不能在迭代中被跟踪。可执行的粒度参考标准是一到两天内可完成：再大，进度信号出现得太晚；再小，跟踪成本超过管理收益。拆解在就需求与验收标准达成一致后进行，由设计、研发、测试人员各自拆自己承担的部分。
每个任务写清四件事：输入是什么、动作做什么、输出是什么、完成标志是什么。完成标志要可观察，例如“接口在测试环境返回约定字段并通过联调用例”，而不是“开发完成”。输入缺失的任务先补输入再排期，避免执行到一半停下来等材料。
负责人、依赖关系和前后顺序在拆解时一并标注。负责人是任务的第一责任人，不等于唯一执行人；依赖关系写明依赖对象和需要的时间点；前后顺序只标真正存在先后的任务，可以并行的不强行串行，保留调整空间。
验收口径要与目标对应。每个条目下的任务集合完成后，应能回答该条目对目标检验方式的贡献；对应不上的任务，要么是拆解偏了，要么是条目本身不该进入本次迭代，在规划会上就调整掉。
| 字段 | 填写内容 | 完成标志示例 |
|---|---|---|
| 任务名称 | 动词开头的具体动作 | “完成验证码接口联调” |
| 输入 | 依赖的文档、接口、环境或数据 | 接口文档已评审、测试环境可用 |
| 动作 | 执行内容与范围边界 | 覆盖发送、校验、失败重试三个分支 |
| 输出 | 可交付的产物 | 联调通过的接口与用例记录 |
| 完成标志 | 可观察的判定条件 | 用例全部通过并留痕 |
| 负责人 | 第一责任人 | 明确到人 |
| 依赖 | 依赖对象与需要时点 | 依赖第三方字段，第二周周三前到位 |
| 验收口径 | 对应条目的验收标准 | 对应“全流程通过”中的登录环节 |
规划会前后的角色分工与交付物
规划会前后三个角色各有明确产出，交接靠交付物确认，而不是靠口头同步。产品负责人对目标与条目范围负责，Scrum Master对会议过程与计划的可执行性负责，开发团队对拆解粒度与工作量判断负责。
| 角色 | 会前 | 会中 | 会后 |
|---|---|---|---|
| 产品负责人 | 按优先级规划候选需求至迭代，写出迭代目标初稿，补齐验收口径 | 说明目标与条目取舍理由，确认验收标准 | 维护目标与范围变更的入口，回应执行中的口径问题 |
| Scrum Master | 确认会议输入齐全，准备容量参考数据 | 引导按目标筛选条目，控制附带项数量，记录未决问题 | 确认计划冻结，登记变更请求，跟踪阻塞项 |
| 开发团队 | 预读候选条目，标记技术依赖与风险 | 拆解任务，标注负责人、依赖与完成标志，给出工作量判断 | 按任务执行并更新状态，发现粒度问题当场提出 |
会前准备物包括：迭代目标初稿、候选条目及其验收口径、容量参考数据、已知依赖清单。会中确认物包括：最终目标表述、进入Sprint Backlog的条目清单、任务拆解结果、负责人与依赖标注。会后计划冻结，冻结的含义是范围与目标经确认后不再随意追加，变更走统一入口：提出变更请求，说明对目标的影响，由产品负责人与团队共同判断是替换条目还是排到后续迭代。
跨角色交接的确认方式可以统一为“交付物加确认人”：目标初稿由团队在会上确认，条目验收口径由产品负责人与测试人员共同确认，任务拆解结果由负责人本人确认。确认动作留下记录，后续出现口径分歧时有据可查。
一个两週迭代的整理示例
以下为演示情景，用于说明从目标到任务拆解的完整过程，不代表真实项目数据。
某团队两週迭代，产品负责人给出的目标初稿是“本次迭代面向新注册用户，完成手机号验证码登录流程上线，以测试环境全流程通过并完成灰度验证确认达成”。候选条目有五项：验证码登录主流程、登录失败提示优化、登录页埋点、老用户密码登录改版、后台登录日志查询。按筛选顺序，主流程直接支撑目标，进入；失败提示优化影响目标检验中的异常分支，作为直接支撑进入；埋点属于附带项，本次不进入；密码登录改版与日志查询属于非目标项，排后续迭代。容量参考上两个迭代完成量，主流程加提示优化在容量之内，不再追加条目。
拆解时，主流程拆为接口联调、前端页面接入、异常分支处理、全流程用例验证四个任务，每个任务控制在一到两天。接口联调依赖第三方短信通道字段，标注为第二周周三前到位；前端接入依赖接口联调输出，排在联调之后；异常分支处理与前端接入可并行；全流程用例验证排在最后，完成标志是用例全部通过并留痕。负责人按设计、研发、测试分工标注，测试人员同时负责验收口径的最终确认。
风险处理上，第三方字段是唯一外部依赖，会上约定若周三未到位，先完成本地模拟联调，把真实联调压缩到两天内，同时由Scrum Master登记为阻塞项每日跟踪。取舍说明写进计划：埋点延后不影响目标检验，密码登录改版涉及范围较大，单独排期更稳妥。
最终Sprint Backlog片段包含：一条迭代目标、两个进入条目、四个任务及其输入、输出、完成标志、负责人和依赖标注，以及一条阻塞跟踪记录。这份片段就是规划会的交付物，会后直接作为执行依据。
规划会后保持可执行粒度的检查
计划的可执行性在迭代中会变化，检查的目的是尽早发现粒度失效并当场调整，而不是等到迭代结束再解释偏差。
每日同步重点看三件事：任务是否仍在原定粒度内推进，出现连续两天没有状态变化的任务要当场拆小或换人；阻塞是否已登记并有明确解除时点，未登记的阻塞当场补录；当日完成的任务是否达到完成标志，只完成动作未达到标志的不算完成。
燃尽与进度偏差提供趋势信号。燃尽曲线持续高于参考线，说明完成速度低于计划，先检查任务粒度是否过大、完成标志是否过严，再判断是否需要调整范围；曲线突然下探，检查是否有任务被批量标记完成但验收未做。偏差判断结合任务状态和阻塞记录一起看，单看曲线容易误判。
调整有明确触发条件：任务连续超出预估时间一倍以上，重拆；阻塞在约定时点未解除且影响目标检验，由产品负责人决定替换条目或缩小范围；新增请求与目标无直接关系，不进入本次迭代，登记到后续候选。范围调整要同步更新目标表述下的条目清单，保持计划与目标一致。
迭代结束时，未完成项逐条重新评估：仍支撑原目标且优先级未变的，回到产品Backlog重新参与下个迭代的筛选；目标已变化或优先级下降的，重新排序或关闭。未完成项不默认结转，避免Sprint Backlog变成只增不减的清单。回顾会上可用燃尽图、工时日志等数据复盘进度与质量偏差，把粒度判断的经验带入下个迭代。
用ONES承载目标、条目与任务状态
上述动作落到工具里，需要三类记录：迭代目标、进入迭代的条目、拆解后的任务及其状态。ONES的迭代规划场景中，产品负责人可依据需求优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审，这对应本文的条目筛选环节；迭代目标可以作为迭代说明或迭代内的工作项记录，与进入的条目放在同一迭代下，便于会上对照目标逐条确认。
拆解环节，团队就本次迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务将需求拆分，方便后续处理和跟踪；功能复杂的需求还可以用子工作项拆解并关联研发和测试任务，把需求、研发、测试环节串联起来。这与任务拆解字段表中的负责人、依赖和完成标志标注相对应，拆解结果直接成为迭代内的执行单元。
迭代进行中，团队成员围绕迭代要完成的需求完成自己拆解的任务，通过敏捷看板管理任务状态；每日站立会议借助看板对齐进度与风险、排除问题，燃尽图则用于观察完成趋势。规划会后的偏差发现因此有了固定入口：看板上的停滞任务、登记的风险项和燃尽趋势共同构成检查依据。
迭代完成并发布后，团队可召开回顾会，通过燃尽图、工时日志等数据报表复盘进度、质量和成本偏差。未完成项在迭代结束时逐条重新评估的处理方式，可以在回顾前结合迭代内工作项清单完成：仍支撑目标的回到产品待办列表参与下轮筛选，不再支撑的重新排序或关闭，保持“重新评估、不默认结转”的规则落地。
常见问题
迭代目标写不出可检验的检验方式，还能开始规划吗？
建议先返工再进入条目筛选。检验方式写不出来，通常说明期望结果本身不可观察，或者范围过大。处理方式有两种：把目标缩小到一个可验证的用户场景或一条业务链路；把结果从“推进”“优化”这类动作词改成可交付的状态，例如“流程上线并通过灰度验证”。
返工在规划会前由产品负责人完成，会上只做确认。带着模糊目标进入筛选，条目取舍会变成凭感觉排序，会后也很难判断计划是否达成。
规划会开完后，业务方临时插入一个紧急需求，应该直接加进Sprint Backlog吗？
先判断它与迭代目标的关系。与目标检验无直接关系的请求，登记到后续候选，不进入本次迭代；确实影响目标达成或属于必要依赖的，走统一变更入口：说明对目标的影响，由产品负责人与团队共同判断是替换掉某个低支撑条目，还是缩小范围。
直接追加会让容量超出历史完成量，连带影响原有条目的完成质量。替换或缩小范围后，同步更新目标下的条目清单，保持计划与目标一致。
任务拆到一两天粒度后，执行中还是经常出现长时间没进展，怎么排查？
先看任务本身是否真的拆到位。常见原因是任务虽然写小了，但完成标志定得太宽，例如“开发完成”无法观察，执行人一直在等一个说不清的结束条件。把完成标志改成可观察的判定条件，例如“接口在测试环境返回约定字段并通过联调用例”。
再看阻塞是否已登记。依赖方未到位、环境不可用这类问题如果没有明确解除时点，任务会停在原地。每日同步中把连续两天没有状态变化的任务拿出来，当场拆小、换人或补录阻塞，比等到迭代结束再解释偏差更有效。
迭代结束时未完成的工作，什么情况下可以带回下个迭代？
带回的前提是重新评估，而不是默认结转。逐条检查两项：是否仍支撑原迭代目标，优先级是否仍然靠前。两项都成立的，回到产品Backlog重新参与下个迭代的筛选；目标已变化或优先级下降的，重新排序或关闭。
这样做可以避免Sprint Backlog变成只增不减的清单，也能让下个迭代的目标和条目重新对齐，而不是继承上一轮的遗留包袱。
团队规模较小、角色兼任时，规划会前后的分工怎么简化？
角色可以兼任，交付物不能省。小团队里产品负责人可能同时承担Scrum Master的部分工作，但会前仍要交出迭代目标初稿和候选条目的验收口径，会中仍要完成条目筛选和任务拆解，会后仍要有一个变更入口。
简化的是会议形式和确认人数，不是判断依据。目标自检、条目筛选顺序、任务拆解字段这几项保留下来，团队对“做什么、做到什么程度”才有共同判断。
