迭代目标写得太虚，团队执行时容易各做各的；写得太细，又变成任务清单。本文提供一张可直接复制的迭代目标表，用七个字段把目标陈述、关键结果、Sprint Backlog 条目、容量依据、验收口径、风险依赖和未完成项处理约定放在同一行里，并说明每个格子怎么填、哪些不能空、迭代中如何更新。适合正在规范迭代计划的 Scrum 团队、项目组和研发负责人参考。
要点总览（TL;DR）
- 迭代目标表以“一个迭代一行”组织，保留七类核心字段：目标陈述、关键结果、Sprint Backlog 条目、容量依据、验收口径、风险与依赖、未完成项处理约定。
- 目标陈述写业务结果，关键结果写指标名称、当前值与目标值；每条关键结果至少对应一条 Backlog 条目，条目总量与容量匹配。
- 目标陈述、关键结果、Sprint Backlog 条目、容量依据、验收口径为必填；风险与依赖、未完成项处理约定可按团队情况选填，小团队可用四项精简集。
- 迭代中调整范围时同步核对关键结果与容量；未完成工作按约定逐条重新评估，决定纳入下一迭代、拆分或移回产品待办列表。
- 模板随团队成熟度调整，保持字段名称稳定，便于历史迭代对比与复盘。
可复制空白模板：迭代目标表
这张表以“一个迭代一行”为基本结构。目标陈述与关键结果分行填写，其余字段按列展开。复制到文档或表格工具后，把示例文字替换为团队实际内容即可使用。
| 字段 | 填写内容 |
|---|---|
| 迭代名称与周期 | （如：Sprint 12，3月4日—3月15日） |
| 迭代目标陈述 | （一句话说明本迭代要达成的业务结果，面向用户或业务价值） |
| 关键结果 1 | （可度量的结果指标、当前值、目标值） |
| 关键结果 2 | （可度量的结果指标、当前值、目标值） |
| 关键结果 3 | （可度量的结果指标、当前值、目标值，按需增减行数） |
| 对应 Sprint Backlog 条目 | （列出支撑上述关键结果的需求或任务编号与名称） |
| 容量依据 | （团队可用人力、历史速率、本迭代占用工时、预留缓冲） |
| 验收口径 | （谁在什么时间、依据什么标准判定目标达成） |
| 风险与依赖 | （外部依赖、技术风险、人员变动及应对措施） |
| 未完成项处理约定 | （迭代结束时未完成工作的评估方式与去向） |
表格的行数可以按关键结果数量增减，但七类核心字段建议保留：目标陈述、关键结果、Sprint Backlog 条目、容量依据、验收口径、风险与依赖、未完成项处理约定。迭代名称与周期作为定位信息放在首行，便于归档和检索。
字段说明：每个格子填什么
模板能否用起来，取决于每个字段是否有明确的填写口径。下表逐字段说明含义、写法要求和常见问题。
| 字段 | 含义 | 填写口径 | 常见写法问题 |
|---|---|---|---|
| 迭代目标陈述 | 本迭代要交付的业务结果 | 用一句话描述用户或业务获得的变化，包含对象和结果，避免罗列任务 | 写成“完成登录模块开发”这类任务描述，缺少价值指向 |
| 关键结果 | 判断目标是否达成的可度量结果 | 每条包含指标名称、当前值、目标值和时间范围，2—4 条为宜 | 指标无法取数，或目标值与当前值口径不一致 |
| Sprint Backlog 条目 | 支撑关键结果的具体需求与任务 | 写编号与名称，确保每条关键结果至少对应一条 Backlog 条目，条目总量与容量匹配 | Backlog 条目与关键结果脱节，出现“为目标之外的工作” |
| 容量依据 | 团队本迭代可投入的工作量 | 写明可用人数、可用天数、历史平均速率、本迭代请假与支持占用、预留缓冲比例 | 只写“按团队能力安排”，没有取数来源 |
| 验收口径 | 目标达成的判定方式 | 写明判定人、判定时间点、依据的数据或演示结果 | 验收标准停留在“功能可用”，无法判定通过与否 |
| 风险与依赖 | 影响目标达成的外部条件和不确定性 | 逐条列出依赖方、风险描述、应对措施和责任人 | 只写“有风险”，没有具体依赖对象和应对动作 |
| 未完成项处理约定 | 迭代结束时未完成工作的处理规则 | 约定重新评估的参与人、评估维度（价值、紧迫性、依赖变化）和去向 | 默认全部结转到下一迭代，导致 Backlog 持续膨胀 |
关键结果的可度量口径需要特别注意。指标应能在迭代结束时直接取数或通过演示验证，例如“下单转化率从 3.2% 提升到 3.8%”“接口平均响应时间从 800ms 降到 500ms”。如果指标依赖外部数据且迭代内无法获取，应改用团队可观测的替代指标，并在验收口径中说明。
Sprint Backlog 条目与目标的对应关系是这张表的核心约束。每条关键结果都应能找到支撑它的 Backlog 条目，反过来，每条 Backlog 条目也应说明服务于哪条关键结果。出现无法归属的条目时，要么补充关键结果，要么将该条目移出本迭代。
必填与选填：哪些字段不能空
七个核心字段并非在所有团队、所有迭代中都同等重要。下表区分必填与选填，并说明理由和适用场景。
| 字段 | 属性 | 理由 | 适用场景 |
|---|---|---|---|
| 迭代目标陈述 | 必填 | 没有目标，团队无法判断优先级取舍 | 所有迭代 |
| 关键结果 | 必填 | 目标是否达成需要可验证的依据 | 所有迭代 |
| Sprint Backlog 条目 | 必填 | 目标需要落到具体工作项才能执行 | 所有迭代 |
| 容量依据 | 必填 | 承诺目标前需要确认团队可承载的工作量 | 所有迭代 |
| 验收口径 | 必填 | 避免迭代结束时对“是否达成”产生分歧 | 所有迭代 |
| 风险与依赖 | 选填 | 无外部依赖或风险较低的迭代可简化 | 跨团队协作、依赖外部交付、技术不确定性强时填写 |
| 未完成项处理约定 | 选填 | 团队已形成稳定惯例时可在团队公约中统一约定 | 新组建团队、首次合作、历史结转较多的团队建议填写 |
小团队可以采用精简填写集：迭代目标陈述、关键结果、Sprint Backlog 条目、容量依据四项。验收口径可以并入关键结果的目标值中，风险与依赖在每日站会口头同步。精简的前提是团队对验收标准有共识，且迭代周期较短、外部依赖少。
字段缺失时的处理约定同样需要提前明确。目标陈述缺失的迭代不应进入计划会议；关键结果缺失时，至少补充一条可验证的完成标准；容量依据缺失时，先补齐人力与工时数据再承诺范围。风险与依赖字段留空表示“本迭代无已知外部依赖”，而非“未评估”。
填写示例：一个完整迭代目标
以下示例演示一张填写完整的迭代目标表。示例为演示情景，团队名称和数据均为虚构，字段顺序与空白模板一致。
| 字段 | 填写内容 |
|---|---|
| 迭代名称与周期 | Sprint 12，3月4日—3月15日，共 10 个工作日 |
| 迭代目标陈述 | 让新注册用户在首次登录后 3 分钟内完成首个核心操作，降低新用户流失 |
| 关键结果 1 | 新用户引导完成率从 41% 提升到 60%（统计口径：注册后 24 小时内完成引导步骤） |
| 关键结果 2 | 首次核心操作平均耗时从 5 分 20 秒降到 3 分钟以内（埋点数据，取中位数） |
| 关键结果 3 | 引导流程相关客诉从每周 12 条降到 5 条以下（客服工单标签统计） |
| 对应 Sprint Backlog 条目 | REQ-231 引导步骤精简为 3 步；REQ-235 首屏加载优化；REQ-240 引导进度提示组件；TASK-118 埋点补充与看板配置 |
| 容量依据 | 团队 5 人，本迭代可用 42 人天（扣除 1 人年假 2 天、1 人支持线上问题 1 天）；近三个迭代平均速率 38 点，本迭代承诺 36 点，预留约 10% 缓冲应对线上问题 |
| 验收口径 | 3月15日迭代评审会上，由产品负责人依据埋点看板数据判定关键结果 1 和 2；关键结果 3 由客服主管提供工单统计，统计周期为迭代结束后一周，作为观察项记录 |
| 风险与依赖 | 依赖数据平台团队在 3月8日前完成埋点字段上线（责任人：数据平台张工）；首屏优化涉及 CDN 配置变更，需运维在 3月11日前完成审批；若埋点延迟，关键结果 1 改用灰度环境数据判定 |
| 未完成项处理约定 | 迭代结束时未完成的 Backlog 条目，由产品负责人与团队在回顾会上逐条重新评估价值、紧迫性和依赖变化，决定纳入下一迭代、拆分为更小条目或移回产品待办列表；不默认整体结转 |
这份示例中，三条关键结果分别对应不同的 Backlog 条目，容量依据写明了人数、可用人天、历史速率和缓冲比例，验收口径明确了判定人和数据来源。风险与依赖部分给出了具体的依赖方、时间点和备选方案，未完成项处理约定则把“重新评估”落实到参与人和评估维度上。
调整与维护：迭代中如何更新这张表
迭代目标表在计划会议确定后并非一成不变。范围调整、每日跟进和评审回顾三个阶段各有对应的更新规则。
范围调整时的字段更新规则
迭代中新增或移除 Backlog 条目时，先判断是否影响关键结果。若新增条目服务于现有目标，补充到 Sprint Backlog 条目列并核对容量依据是否仍成立；若新增条目引入新的业务结果，应评估是否修改目标陈述和关键结果，并与产品负责人确认后再更新。移除条目时同步检查对应关键结果是否仍有支撑，避免出现“目标还在、工作项已撤”的情况。每次调整记录调整日期和原因，便于回顾时追溯。
每日跟进中的检查点
每日站会围绕三个问题检查这张表：关键结果的当前值与目标值差距是否在收敛；Backlog 条目是否有阻塞，阻塞是否已登记到风险与依赖列；剩余工作量与容量依据中的缓冲是否匹配。团队在迭代过程中围绕要完成的需求推进各自拆解的任务，并通过看板管理任务状态；站会中借助看板对齐迭代进度与风险，发现偏差时及时更新表中的风险与依赖字段。
评审回顾时的记录方式
迭代评审会上，按验收口径逐条判定关键结果是否达成，并在表中记录实际值。未达成的关键结果写明原因：是目标设定偏高、执行受阻，还是外部依赖未兑现。回顾会上可以结合燃尽图、工时日志等数据复盘进度、质量和成本偏差，讨论改进建议；形成的经验可以沉淀到团队知识库，作为下一迭代填写模板的参考。
未完成工作的处理
迭代结束时，未完成的 Backlog 条目按表中约定逐条重新评估，而非默认结转到下一迭代。评估时关注三点：该条目对应的关键结果是否仍然重要；条目本身是否需要拆分或重新澄清；依赖条件是否发生变化。重新评估后决定纳入下一迭代、拆分或移回产品待办列表，并在新迭代的目标表中体现评估结论。
模板随团队成熟度调整
模板本身也需要维护。团队运行几个迭代后，可以回顾哪些字段实际发挥了作用、哪些字段长期空白。若风险与依赖字段连续多个迭代为空且团队外部依赖确实较少，可将其降为选填；若验收口径反复引发争议，则应细化判定标准。调整模板时保持字段名称稳定，避免历史迭代的目标表无法对比。对于使用 ONES 的团队，迭代规划阶段可以将产品待办列表中的需求按优先级规划至对应迭代，并在计划会议上共同评审；目标确定后，团队利用子任务拆分需求，迭代目标表中的 Backlog 条目可以与这些工作项对应，站会和回顾时通过看板与报表核对进展，回顾结论可用 ONES Wiki 沉淀为团队知识库。
常见问题
迭代目标表里的关键结果设几条比较合适？
一般 2—4 条为宜。条数过多会让团队难以聚焦，也容易让关键结果退化成任务清单。判断标准是：每条关键结果都能在迭代结束时取数或通过演示验证，并且都能找到对应的 Sprint Backlog 条目。如果某条关键结果找不到支撑它的工作项，说明它更适合放到后续迭代；如果某条 Backlog 条目归属不到任何关键结果，需要补充关键结果或把该条目移出本迭代。
迭代中途插入紧急需求，目标表应该怎么改？
先判断新需求是否服务于现有目标。若服务于现有目标，补充到 Sprint Backlog 条目列，同时核对容量依据中的缓冲是否还够用；若新需求带来新的业务结果，需要与产品负责人确认是否修改目标陈述和关键结果。无论哪种情况，都记录调整日期和原因。若插入需求导致原有关键结果失去支撑，应同步调整或移除该关键结果，避免出现目标还在、工作项已撤的情况。
团队规模很小，七个字段都要填吗？
可以采用精简填写集：迭代目标陈述、关键结果、Sprint Backlog 条目、容量依据四项。验收口径可以并入关键结果的目标值中，风险与依赖在每日站会口头同步。精简的前提是团队对验收标准已有共识，迭代周期较短且外部依赖少。团队扩大或开始跨团队协作后，再逐步补回验收口径和风险与依赖字段。
未完成的工作为什么建议重新评估，而不是直接带到下一迭代？
直接结转会让 Backlog 持续膨胀，也会让团队忽略条目本身可能已经过时。重新评估时关注三点：该条目对应的关键结果是否仍然重要；条目是否需要拆分或重新澄清；依赖条件是否发生变化。评估后决定纳入下一迭代、拆分或移回产品待办列表，并把结论写进新迭代的目标表。这样下一迭代的范围仍然与容量匹配，目标也保持清晰。
用 ONES 管理迭代时，这张目标表和系统里的工作项怎么对应？
在 ONES 中，产品负责人可以根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；就当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务拆分需求。目标表中的 Sprint Backlog 条目可以与这些工作项对应，站会和回顾时通过敏捷看板与报表核对进展，回顾结论可用 ONES Wiki 沉淀为团队知识库。
