迭代目标由三类输入共同确定：上一迭代的完成情况与遗留项、当前产品目标与需求池中已排序的候选项、团队可投入的产能与关键依赖。做法是先明确本迭代要改变的业务或用户结果，再拆成可验证的验收口径，最后用产能和依赖做一次可行性裁剪，形成团队共同确认、可逐条验收的目标。本文按这一顺序给出操作步骤、角色交付物与检查清单，范围限定在单次迭代的目标确定环节。
要点总览（TL;DR）
- 迭代目标由三类输入共同确定：上一迭代完成情况与遗留项、产品目标与需求池排序结果、团队产能与关键依赖，会前按负责人和更新时点备齐。
- 目标用结果导向句式写成一句话，并为每条目标写明验收口径（判断依据、判断方式、确认人），同时列出本迭代不做的候选项及原因。
- 可行性裁剪把目标拆到角色粒度，比对可投入产能，计入跨团队依赖与外部等待时间；超载时先裁弱关联支撑项，再降级增强项，最后才缩减主目标范围。
- 遗留项需重新评估后分为纳入、降级、关闭，不默认自动结转；目标变更由产品负责人与迭代负责人共同确认，追加需求进入需求池。
- 目标确认后用完成检查清单逐项核对，全部通过再进入执行，清单同时作为迭代回顾的对照材料。
确定迭代目标前先备齐哪三类输入
迭代目标的质量很大程度上取决于会前材料的完整度。把三类输入在计划会前整理到位，讨论才能集中在取舍上，而不是在会议上临时翻找数据。每类输入都需要指定负责人和更新时点，避免用过期的信息做决策。
第一类：上一迭代的完成情况与遗留项
复盘结论要回答三个问题：计划内的工作完成了哪些、未完成的原因是什么、遗留项现在处于什么状态。遗留项不能默认进入下一迭代，需要重新评估优先级——原来的业务价值是否仍然成立、依赖是否已经解除、继续做的成本是否发生变化。评估结论分为纳入、降级、关闭三种，每种都要写明理由。
第二类：产品目标与需求池候选项的排序依据
需求池的梳理方法属于另一主题，本文只引用其排序结果。会前需要拿到的是：当前产品阶段要达成的业务目标、候选项的优先级顺序、每个候选项的价值判断依据（用户反馈、数据表现、业务方诉求等）。排序依据要能被团队理解，否则讨论时容易退回“谁声音大听谁的”。
第三类：团队产能、关键依赖与外部约束
产能按角色估算，包括可用人天、休假与并行任务占用。关键依赖要列出跨团队协作事项、外部供应商或审批的等待时间。外部约束包括发布窗口、合规检查、环境可用性等。这些信息在会前由迭代负责人汇总，会上直接用于可行性判断。
| 输入类别 | 来源 | 负责人 | 更新时点 |
|---|---|---|---|
| 上一迭代完成情况与遗留项 | 迭代回顾记录、任务状态、燃尽图 | 迭代负责人 | 计划会前2个工作日 |
| 产品目标与候选项排序 | 产品目标文档、需求池 | 产品负责人 | 计划会前2个工作日 |
| 产能、依赖与外部约束 | 排班表、依赖方确认、发布日历 | 迭代负责人与各角色代表 | 计划会前1个工作日 |
把候选项收敛成一条可验收的迭代目标
候选项是一堆待做的事，迭代目标是一句能判断做没做到的话。收敛的动作是把候选项按“要改变什么结果”重新归类，再从每组中选出本迭代真正要推进的部分。
用结果导向的句式描述目标
推荐句式：“让【目标用户/业务对象】能够【完成什么动作/获得什么结果】，以【可观察的信号】判断达成。”例如“让新注册用户在首次登录后完成引导流程，以引导完成率作为判断信号”。任务清单式的表述（“完成登录页改版、完成引导弹窗开发”）只说明投入，不说明结果，遇到范围调整时无法判断目标是否还成立。
为每条目标写出验收口径
验收口径要包含判断依据、判断方式和责任确认人。判断依据可以是功能行为、数据指标或用户反馈；判断方式说明在哪里看、由谁验证；确认人负责在迭代结束时给出结论。口径写得越具体，迭代中的范围争议越少。
控制目标数量，明确不做什么
一个迭代通常聚焦一到两条主目标，其余工作作为支撑项列出。同时要写明本迭代明确不做的候选项及原因，这份“不做清单”在后续有人追加需求时是重要的沟通依据。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 目标表述 | 结果导向句式，一句话 | 让新注册用户完成首次引导流程 |
| 目标用户/对象 | 具体到人群或业务环节 | 新注册且首次登录的用户 |
| 验收口径 | 判断依据＋判断方式 | 引导完成率达到约定值，由数据看板验证 |
| 确认人 | 对验收结论负责的角色 | 产品负责人 |
| 本迭代不做 | 列出被排除的候选项及原因 | 引导内容个性化，依赖内容平台排期 |
用产能与依赖做可行性裁剪
目标写得清楚，还要确认做得完。可行性裁剪的动作是把目标拆到任务粒度，按角色比对产能，再把依赖等待时间计入排期，超出部分按优先级裁剪或降级。
按角色估算产能并与工作量比对
把每条目标拆成设计、开发、测试等角色的任务，估算工作量后与该角色的可投入人天比对。比对结果通常有三种：有余量、基本匹配、超载。有余量时可以补充支撑项；超载时必须裁剪，不能靠加班消化，否则下一迭代的遗留项会继续累积。
识别跨团队依赖与外部等待时间
依赖项要写明依赖方、需要对方交付什么、预计等待多久、如果延迟的替代方案。外部等待时间要计入排期，例如审批、环境申请、第三方接口联调。依赖没有确认时间的，按风险项处理，不按已就绪排入计划。
超载时的裁剪顺序与降级方案
裁剪按以下顺序进行：先去掉与本迭代主目标关联最弱的支撑项；再将部分目标降级为“完成核心路径、延后增强项”；最后才考虑缩减主目标范围，且缩减需经目标确认人同意。每次裁剪后更新目标版本，保留裁剪记录，便于回顾时分析估算偏差。
| 核对项 | 核对内容 | 结论填写 |
|---|---|---|
| 角色产能 | 各角色可投入人天与任务估算比对 | 余量／匹配／超载 |
| 跨团队依赖 | 依赖方、交付物、等待时间、替代方案 | 已确认／待确认／有风险 |
| 外部约束 | 发布窗口、审批、环境可用性 | 满足／需调整排期 |
| 裁剪结果 | 裁剪项、降级项、调整后的目标版本 | 版本号与确认人 |
角色分工与各环节交付物
迭代目标的确定涉及产品、迭代管理和团队三方，职责边界清楚，交接才有节奏。以下分工适用于常规 Scrum 迭代，采用其他迭代节奏的团队可按相同逻辑调整节点名称。
| 角色 | 职责边界 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 产品负责人 | 对目标价值和优先级负责 | 产品目标、需求池排序、业务方诉求 | 提出候选项与价值判断，参与目标表述与验收口径确认 | 排序后的候选项清单、验收口径确认意见 |
| 迭代负责人 | 对过程组织和可行性负责 | 复盘结论、产能与依赖信息 | 汇总输入、组织计划会、主持裁剪、维护目标版本 | 输入清单、产能与依赖核对表、裁剪后的目标版本 |
| 团队成员 | 对估算和承诺负责 | 目标草案、任务拆分要求 | 拆分任务、给出估算、确认依赖、承诺可完成范围 | 任务拆分与估算结果、依赖确认 |
目标确认的决策人是产品负责人与迭代负责人共同确认，团队对可行性有异议时在计划会上提出并当场调整。迭代开始后如需变更目标，由提出方说明原因，经两位确认人同意后更新目标版本并通知全员；未经确认的追加需求进入需求池，不直接插入当前迭代。
在目标确认与后续跟踪的承载上，团队可以把达成一致的需求与验收标准记录在迭代规划中，再将需求拆分为子任务分配负责人，通过看板跟踪任务状态。ONES Project 支持建立需求池、规划迭代，将需求和相关任务规划至迭代并分配负责人，也提供任务工时统计与看板、燃尽图等进度视图，适合把上述输入、目标版本和执行状态放在同一处对照。具体字段配置与套餐支持范围需按团队实际情况确认。
一个完整示例：从候选项到确认的迭代目标
以下为演示情景，用于说明步骤如何串联，数据为示意值。
输入材料与候选项
某团队上一迭代遗留两项工作：支付失败提示优化（完成约七成）、订单导出格式调整（未开始）。复盘结论是支付提示优化因依赖风控文案审核而延迟，订单导出优先级下调。产品目标为本季度提升下单转化，需求池候选项依次为：结算页加载优化、支付失败提示优化、优惠券入口改版、订单导出格式调整。产能方面，前端可投入约八人天、后端约六人天、测试约四人天；结算页加载优化依赖运维侧接口性能排查，预计等待三个工作日。
目标表述与验收口径
收敛后形成一条主目标：“让提交订单的用户在结算页更快完成下单，以结算页加载时长和下单完成率作为判断信号。”验收口径写明：加载时长达到约定阈值，由性能监控数据验证；下单完成率对比上一迭代有可观察变化，由数据看板验证；确认人为产品负责人。支撑项为支付失败提示优化，验收口径为提示文案上线且覆盖主要失败场景。本迭代不做优惠券入口改版和订单导出格式调整，前者依赖设计资源，后者优先级下调。
裁剪过程与最终确认
任务拆分后，前端工作量估算超出可投入人天约两天，且运维排查存在三天等待。裁剪顺序执行：先去掉支付失败提示优化中的非主要失败场景覆盖，缩小为两个高频场景；再将结算页加载优化的增强项（骨架屏动画）降级到下一迭代。调整后工作量与产能基本匹配，依赖等待时间计入排期并准备了降级方案——若运维排查延迟，先上线已定位的优化项。产品负责人与迭代负责人共同确认目标版本，团队在计划会上承诺范围，遗留的订单导出格式调整经重新评估后关闭。
迭代目标确定后的完成检查
目标确认后，用以下清单逐项核对，全部通过才进入执行。任何一项未通过，回到对应环节补充，不带着缺口开工。
- 每条目标都有结果导向的表述，能回答“要改变什么结果”。
- 每条目标都有验收口径，写明判断依据、判断方式和确认人。
- 目标数量控制在聚焦范围内，并附有本迭代不做清单及原因。
- 每项遗留工作都经过重新评估，结论为纳入、降级或关闭，并写明理由，没有默认结转。
- 任务已拆分到角色粒度，估算与各角色可投入产能完成比对。
- 跨团队依赖已确认交付物和时间，未确认的依赖已列为风险并写明应对方案。
- 外部约束（发布窗口、审批、环境）已核对，排期与之不冲突。
- 目标版本、裁剪记录和确认人已记录，团队成员均已知晓。
- 变更路径已明确：追加需求进入需求池，目标变更需经确认人同意。
这份清单同时可作为迭代回顾的对照材料：回顾时逐项检查当初的判断是否成立，估算偏差出现在哪个环节，为下一迭代的输入准备提供依据。
常见问题
遗留项在什么情况下应该关闭，而不是纳入下一迭代？
遗留项经过重新评估后，如果原来的业务价值已不成立、依赖长期无法解除，或继续投入的成本明显高于预期收益，就应关闭并写明理由。关闭不等于放弃记录，理由要保留在复盘材料中，便于后续有人重提时快速判断。若价值仍成立但优先级低于当前主目标，则选择降级，放入需求池等待后续排序。
团队对目标可行性有异议时，应该在哪个环节解决？
异议应在计划会上当场提出并调整，而不是带着分歧进入执行。常见做法是让提出异议的成员说明具体依据，例如某角色产能不足、依赖未确认或估算偏差，再由迭代负责人主持裁剪。若当场无法达成一致，可先缩小主目标范围或把争议部分降级为支撑项，待依赖确认后再补充。目标确认后如需变更，由提出方说明原因，经产品负责人与迭代负责人同意后更新目标版本并通知全员。
验收口径写到什么程度才算够用？
验收口径至少要能回答三个问题：看什么（判断依据）、在哪里看和由谁验证（判断方式）、谁给出最终结论（确认人）。判断依据可以是功能行为、数据指标或用户反馈；判断方式要具体到数据看板、测试结果或用户验证场景。口径写得越具体，迭代中围绕范围是否完成的争议越少。对于难以量化的目标，可以用可观察的行为变化替代，但要事先约定观察方式。
一个迭代安排几条主目标比较合适？
常规做法是聚焦一到两条主目标，其余工作作为支撑项列出。主目标过多会导致产能分散，裁剪时也难以判断取舍顺序。确定主目标后，同步写明本迭代明确不做的候选项及原因，这份不做清单在后续有人追加需求时是重要的沟通依据。团队规模、依赖复杂度不同，具体数量可按实际情况调整，判断标准是目标能否被逐条验收且工作量与产能匹配。
目标确定后，迭代中途追加的需求怎么处理？
未经确认的追加需求进入需求池，不直接插入当前迭代。如果追加需求确实影响主目标成立，由提出方说明原因，经产品负责人与迭代负责人共同确认后更新目标版本，并同步调整裁剪方案与排期。把变更路径在目标确认时就写清楚，可以减少执行期的临时插入，也便于回顾时分析变更频率和来源。
