迭代目标的确定，是把产品方向、团队容量和外部约束收敛成一个可承诺结果的过程。先盘点输入，再测算本轮真实可用容量，把候选需求裁剪到容量范围内，提炼一句可验证的迭代目标，最后拆成Sprint Backlog并由团队共同确认。本文按这一顺序给出操作步骤、角色分工、完整示例和收尾检查清单。
要点总览（TL;DR）
- 迭代目标不是规划会上临时拍定，而是先盘点产品方向、上轮遗留、团队容量和外部约束四类输入，再进入测算与筛选。
- 确定过程分五步：测算可用容量、按优先级裁剪候选需求、提炼一句聚焦单一成果的目标、拆成Sprint Backlog并写清验收口径、团队共同确认承诺。
- 可验证的目标要回答面向谁、达成什么结果、用什么观察，并为每个目标配一条评审时能直接核对的达成判定标准。
- 范围调整只在外部依赖失效、重大缺陷或需求价值不成立时启动；未完成工作在新一轮重新评估价值、拆分与优先级，不默认结转。
- 规划收尾用五项检查核对：目标聚焦、判定标准可观察、Backlog在容量内、依赖风险有人跟进、团队共同确认。
确定迭代目标前要准备哪些输入
迭代目标来自对四类输入的整理与判断，规划会现场临时拼凑往往导致目标空泛或承诺超载。进入规划前，产品负责人和迭代负责人应把下列输入准备齐全，并标明每项的负责人与获取时点。
| 输入类别 | 具体内容 | 负责人 | 获取时点 |
|---|---|---|---|
| 产品方向与优先级 | 产品负责人对近期价值的判断，候选需求及其相对优先级 | 产品负责人 | 规划会前2–3个工作日 |
| 上轮迭代遗留 | 未完成事项清单、未完成原因、当前状态 | 迭代负责人 | 上轮回顾会后 |
| 团队容量基线 | 人员可用工时、休假安排、支持性事务占用 | 迭代负责人 | 规划会前1个工作日 |
| 依赖与外部约束 | 跨团队接口、发布窗口、合规节点 | 相关方对接人 | 规划会前确认 |
四类输入中，产品方向决定“做什么”，容量基线决定“能做多少”，遗留事项和外部约束决定“哪些必须先处理或必须避开”。上轮遗留不能默认结转，需要在新一轮中重新判断价值与优先级；依赖信息要具体到接口方和时间点，否则无法在规划时评估风险。
迭代目标确定的核心步骤
整个确定过程分五步推进，每步都有明确输入、动作、输出和完成标志。前一步的输出是后一步的输入，任何一步没有产出就进入下一步，目标就容易变成口号。
第一步：测算可用容量
输入是团队容量基线，动作是逐人核算本轮可用工时并扣除休假、支持性事务和会议占用，输出是可承诺的工作量上限。完成标志是团队对“本轮最多能承担多少工作”形成一致数字，而不是模糊的“尽量多做”。
第二步：筛选并裁剪候选需求
输入是候选需求清单和容量上限，动作是按优先级从高到低选取需求，累计估算工作量逼近但不超过上限，超出部分移出本轮。完成标志是入选需求总量落在容量范围内，且被移出的需求有明确去向，例如回到需求池等待下轮。
第三步：提炼一句迭代目标
输入是入选需求集合，动作是找出这些需求共同服务的那个主要成果，用一句话描述本轮要达成的结果。完成标志是团队能用这句话回答“这一轮为什么做这些事”，并且目标只指向一个主要成果。
第四步：拆成Sprint Backlog并写清验收口径
输入是迭代目标和入选需求，动作是把需求拆成可执行的任务条目，为每条需求写明验收标准。完成标志是每条Backlog条目都能对应到目标，且验收标准具体到可判定通过与否。
第五步：团队共同确认承诺
输入是目标、Backlog和验收口径，动作是团队逐条确认可交付性，记录本轮依赖的假设与已知风险。完成标志是每位成员明确自己承担的工作，假设与风险有记录并指定跟进人。
当候选需求明显多于容量时，取舍发生在第二步：优先保留直接支撑主要成果的需求，把锦上添花或可延后的条目移出，而不是压缩验收标准或让团队超负荷承诺。当容量因休假或支持性事务明显下降时，应在第一步就调低上限，再进入筛选，避免到规划会现场才发现装不下。
迭代目标怎么写才可验证
可验证的目标回答三个问题：面向谁、达成什么结果、用什么观察。推荐句式是“面向【目标用户或场景】，达成【可观察的结果】，通过【观察方式】确认”。目标描述的是本轮结束时应出现的状态，任务清单描述的是过程中的动作，两者不能互相替代。
写作时把模糊动词替换为可观察的结果。“优化登录体验”可以改写为“新用户从注册到首次成功登录的步骤减少到三步以内”；“提升接口稳定性”可以改写为“核心接口在本轮发布后一周内错误率低于约定阈值”；“完善帮助文档”可以改写为“覆盖本轮上线的全部新功能，每篇文档经产品负责人确认可发布”。
每个目标配一条达成判定标准，标准要能在迭代评审时直接核对。例如目标为“让运营人员可以自助导出月度报表”，判定标准可以是“运营人员在不求助研发的情况下完成一次完整导出，且数据与后台一致”。判定标准写不出来，通常说明目标还停留在方向层面，需要继续收敛。
角色分工与各环节交付物
迭代目标由团队共同确定，但各角色在其中的职责边界不同。明确分工可以减少规划会上的反复拉扯，也让每个环节的产出有明确责任人。
| 角色 | 核心职责 | 关键交付物 |
|---|---|---|
| 产品负责人 | 提供优先级与价值判断，对目标方向负责 | 候选需求清单及优先级、目标方向说明 |
| 迭代负责人 | 组织规划、把控容量与范围，维护目标一致性 | 容量测算结果、规划会议记录、范围调整决策记录 |
| 团队成员 | 参与估算与承诺，对可交付性负责 | 任务拆分与估算、验收标准补充、风险提示 |
| 相关方 | 提供依赖与约束信息，参与目标确认 | 接口时间点、发布窗口、合规节点说明 |
产品负责人对“做什么有价值”负责，团队成员对“能否做完、怎么做”负责，迭代负责人负责让两者在容量约束下对齐。相关方在目标确认阶段参与，主要是把外部时间点和依赖讲清楚，避免目标确定后才发现被外部条件卡住。
目标与Backlog确定后，需要一个团队共同可见的承载位置。在ONES中，产品负责人可按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；对需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪。迭代执行中，团队通过敏捷看板管理任务状态，在每日站立会议中借助看板对齐进度与风险；燃尽图可作为评估研发效率的直观参考。迭代完成并发布后，可通过燃尽图、工时日志等报表复盘进度、质量和成本偏差。具体功能范围以实际部署与配置为准。
一个完整的迭代目标确定示例
以下为演示情景，用于说明容量约束下的取舍过程，不对应特定团队的真实数据。
某团队共5人，本轮周期两周。扣除休假、例行支持事务和会议后，测算可用容量约为120人时。候选需求清单共6项，估算合计约180人时，明显超出容量。
规划会上团队按优先级裁剪：保留“订单列表支持按状态筛选”“导出功能增加权限校验”“修复支付回调重复处理缺陷”三项，合计约105人时，留出约15人时的缓冲应对支持性事务。移出的三项中，两项回到需求池等待下轮，一项因依赖外部接口尚未就绪而暂缓。
团队提炼的迭代目标是：“让客服人员可以在订单列表中按状态快速定位订单，并在导出时只看到其权限范围内的数据。”支撑该目标的Backlog包括筛选功能的需求条目、导出权限校验条目及对应测试任务，支付回调缺陷作为保障性条目一并纳入。每条需求写明验收标准，例如筛选结果与后台查询一致、越权导出被拒绝并给出提示。
确认环节中，团队记录了两项风险：外部接口联调时间可能延后，影响筛选功能的部分数据来源；测试环境本轮有半天不可用。两项风险各指定一名跟进人，并在每日站会中检查状态。
迭代中范围调整与未完成工作的处理
目标确定后，默认做法是守住目标、稳定范围。出现以下情况时才启动范围调整：外部依赖确认无法按期就绪、发现影响目标达成的重大缺陷、需求本身被证明价值不成立。调整由迭代负责人组织，产品负责人做价值判断，团队评估影响后共同决定，并记录调整原因。
范围调整后要判断目标是否需要重述。如果被移出的工作不支撑主要成果，目标可以保持不变；如果移出的正是目标的核心支撑，就应重述目标，让目标与Backlog重新一致，避免出现“目标还在、支撑没了”的情况。
未完成工作在新一轮规划中重新评估，而不是默认自动结转。评估分三步：先判断该事项当前是否仍有价值，再判断是否需要拆分得更小以便完成，最后按新的优先级决定是否进入本轮。价值已下降或场景已变化的事项应关闭或回到需求池，而不是因为“上次没做完”就继续占用容量。
完成检查：迭代目标是否定得合格
规划结束前，用下列清单逐项核对。全部通过再宣布目标确定，任一项不通过就回到对应步骤修正。
| 检查项 | 通过标准 |
|---|---|
| 目标是否聚焦单一主要成果 | 能用一句话说清本轮要达成的结果，且不并列多个互不相关的结果 |
| 是否有可观察的达成判定标准 | 评审时可直接核对通过与否，无需再解释口径 |
| Backlog总量是否在容量范围内 | 估算总量不超过容量上限，并留有应对支持性事务的缓冲 |
| 依赖与风险是否已记录并有人跟进 | 每项依赖和风险有描述、有跟进人、有检查时点 |
| 团队是否共同确认承诺 | 每位成员明确自己承担的工作，对可交付性无异议 |
这份清单同时适用于规划收尾和目标调整后的复核。检查通过后，目标、Backlog、验收口径和风险记录应放在团队共同可见的位置，作为迭代中每日跟进和评审回顾的对照基准。
常见问题
团队第一次做容量测算，没有历史工时数据怎么办？
可以先用估算加经验校准的方式起步：按人员可用天数乘以每日有效工时，扣除已知休假、例行支持事务和会议占用，得到一个初始上限；再对照上一轮实际完成的工作量做修正。前几轮把测算结果和实际完成量都记录下来，误差会逐步收敛。关键是让团队对上限形成一个共同认可的数字，并在每轮回顾时校准，而不是追求一次算准。
迭代目标确定后，产品负责人临时插入高优先级需求，应该怎么处理？
先判断这条需求是否支撑当前迭代的主要成果。如果支撑，由迭代负责人组织评估容量影响，明确需要移出哪项工作来腾出空间，并记录调整原因；如果不支撑，放入需求池等待下轮，不挤占本轮容量。插入需求时同步检查目标是否需要重述：移出的工作若是目标的核心支撑，就应重述目标，让目标与Backlog保持一致。
迭代目标一定要只有一个吗？多个目标并行是否可行？
建议聚焦一个主要成果。多个并列目标会分散团队注意力，也让评审时的达成判定变得模糊。如果确实存在必须并行的事项，可以把其中一项作为保障性条目纳入Backlog，例如修复影响主流程的缺陷，但对外表述的迭代目标仍指向那个主要成果。判断标准是：团队能否用一句话说清这一轮为什么做这些事。
未完成的工作为什么不能直接结转到下一轮？
直接结转会让上一轮的判断未经检验就继续占用新一轮容量。正确做法是重新评估三步：该事项当前是否仍有价值，是否需要拆得更小以便完成，按新的优先级是否进入本轮。价值已下降或场景已变化的事项应关闭或回到需求池。这样每一轮的容量都分配给当下最有价值的工作，而不是被历史惯性占满。
目标与Backlog确定后，在协作工具里怎么承载和跟踪？
需要一个团队共同可见的位置存放目标、Backlog、验收口径和风险记录。在ONES中，产品负责人可按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；对需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪。迭代执行中，团队通过敏捷看板管理任务状态，在每日站立会议中借助看板对齐进度与风险；燃尽图可作为评估研发效率的直观参考。具体功能范围以实际部署与配置为准。
