迭代目标是团队在一个迭代周期内希望达成的结果约定，回答“这个迭代要解决什么问题、交付什么结果”。它约束本迭代的范围取舍，是规划、每日跟进、范围调整和评审回顾的共同参照。理解迭代目标，需要同时看清它由什么构成、覆盖到哪里，以及未完成工作为何要在迭代结束后重新评估。
要点总览（TL;DR）
- 迭代目标是团队在一个迭代周期内要达成的结果约定，由一句目标陈述和一组支撑待办构成，用于约束本迭代的范围取舍。
- 迭代目标覆盖本迭代承诺交付的结果及支撑工作，不包括完整产品待办、个人任务清单或长期产品目标。
- 迭代目标在规划阶段结合团队容量形成，在每日跟进中作为范围调整的判断依据，在评审回顾中检验达成情况。
- 迭代目标与产品目标、Sprint Backlog、产品待办、任务清单分属不同层级，混淆会导致目标失去约束力。
- 未完成工作应在迭代结束后重新评估，而非默认结转到下一迭代；把任务清单当目标也是常见误解。
迭代目标的直接定义
迭代目标是团队对一个迭代周期内要达成的结果所做的明确约定。它通常由两部分组成：一句可被团队共同引用的迭代目标陈述，以及一组支撑该目标的产品待办事项。目标陈述说明本迭代聚焦解决的核心问题或要交付的关键结果，支撑待办则把这一结果拆解为可执行、可验收的具体工作。两者缺一不可：只有陈述没有待办，目标无法落地；只有待办没有陈述，团队容易陷入任务堆叠而失去取舍依据。
一个具体的例子可以帮助理解。假设某电商团队的下一个两周迭代，目标陈述为“让新用户在下单流程中完成支付的步骤从五步缩短到三步”。支撑它的待办可能包括：简化收货地址填写、合并支付方式选择页、补充支付失败提示文案、完成对应埋点与回归测试。这些待办共同服务于同一个结果，团队在迭代中判断某项工作是否该做，就看它是否推进这一目标。
从这个定义可以看出，迭代目标是一种结果约定，而非工作量清单。它让团队在迭代开始时对“做成什么样”形成共识，在迭代进行中对“要不要接新需求”有判断依据，在迭代结束时对“是否达成”有检验标准。
迭代目标包括什么、不包括什么
迭代目标覆盖的是本迭代周期内团队承诺交付的结果及其支撑工作。具体来说，它包括：本迭代要解决的核心问题或要交付的关键结果；为实现该结果而从产品待办中选取的待办事项；这些待办对应的验收标准；以及团队对本迭代范围取舍的共同理解。范围之外的需求，即使价值很高，也属于后续迭代的讨论对象。
迭代目标不包括以下内容。它不包括完整的产品待办清单，产品待办是跨迭代持续维护的需求集合，迭代目标只从中选取本周期要做的部分。它不包括某个人的任务清单，任务清单是个人层面的执行分解，迭代目标是团队层面的结果约定。它也不包括长期的产品目标或版本路线图，那些属于更高层级的方向性约定。
关于未完成工作的处理边界需要特别说明：迭代结束时未完成的工作，需要在评审或回顾中重新评估，判断其是否仍有价值、是否调整优先级、是否纳入下一迭代，而不是默认自动结转到下一个迭代。默认结转会让迭代目标失去约束力，团队对承诺的感知也会逐渐模糊。
| 对比项 | 迭代目标 | 产品待办 | 个人任务清单 |
|---|---|---|---|
| 时间范围 | 单个迭代周期 | 跨迭代持续维护 | 个人当日或数日 |
| 主体 | 团队共同承诺 | 产品负责人维护、团队共同细化 | 个人 |
| 核心内容 | 结果约定与支撑待办 | 按优先级排列的需求集合 | 执行层面的具体动作 |
| 作用 | 约束本迭代范围取舍 | 为迭代规划提供来源 | 支撑个人推进工作 |
迭代目标如何形成并发挥作用
迭代目标在迭代规划阶段形成。产品负责人依据优先级从产品待办中提出候选需求，团队在计划会议上共同评审，就本迭代要完成的需求与验收标准达成一致，并结合团队可用容量确定范围，最终形成目标陈述和支撑待办。容量是形成目标时的重要约束：目标应当与团队在一个迭代内实际能完成的工作量相匹配，超出容量的目标会让承诺失去意义。
目标确定后，支撑待办构成迭代的工作基础，团队进一步把需求拆分为可执行、可跟踪的子任务，明确负责人。此时迭代目标与迭代待办共同界定了“本迭代做什么”。在迭代进行中，每日跟进围绕目标展开：团队成员推进各自拆解的任务，通过看板等方式同步状态，在每日站会上对齐进度、暴露风险、排除障碍。当出现新需求或范围调整的讨论时，判断依据就是它是否服务于当前迭代目标；不服务于目标的内容，应进入产品待办等待后续评估，而不是随意插入当前迭代。
迭代结束并发布后，评审与回顾环节检验目标的达成情况。团队对照目标陈述看结果是否交付，借助进度、质量、成本等方面的数据复盘偏差，讨论改进建议。这一检验既是对本迭代承诺的交代，也为下一个迭代目标的形成提供输入。围绕迭代规划、任务拆分、看板跟进和回顾复盘这条流程，ONES 可以承载相应的管理动作：需求与相关任务可规划至迭代并分配负责人，团队围绕工作项和迭代安排协同，及时了解任务状态与待处理事项；迭代中通过敏捷看板管理任务状态，在站会上可视化对齐进度与风险；迭代完成后借助燃尽图、工时日志等报表复盘进度、质量和成本偏差。工具承载的是这些管理动作的记录与呈现，迭代目标本身的约定仍由团队在规划中完成。
迭代目标与相关概念的区别
迭代目标容易与几个相邻概念混淆，区分它们有助于准确使用这一概念。
与产品目标的区别：产品目标是产品在较长周期内希望达到的方向性结果，例如提升某类用户的留存或进入某个市场；迭代目标是产品目标在单个迭代内的阶段性落地，时间跨度短、范围具体、可在一个迭代内检验。产品目标指导多个迭代的方向，迭代目标则约束当前这一个迭代的取舍。
与 Sprint Backlog 的区别：Sprint Backlog 是团队为达成迭代目标而选定的待办集合及其执行计划，是“要做的工作”；迭代目标是这些工作共同指向的“要达成的结果”。Sprint Backlog 会随执行细化而调整，迭代目标则在整个迭代中保持相对稳定，作为判断调整是否合理的基准。
与产品待办的区别：产品待办是跨迭代维护的、按优先级排列的需求全集，是迭代目标的来源；迭代目标只覆盖其中被选入本迭代的部分。产品待办可以很长且不断变化，迭代目标必须聚焦且在本迭代内可完成。
与团队任务清单的区别：任务清单是执行层面的动作分解，回答“谁在做什么”；迭代目标回答“团队一起要达成什么”。任务清单可以逐条勾选完成，但任务全部完成不等于目标达成，目标是否达成要看约定的结果是否交付。
| 概念 | 回答的问题 | 时间跨度 | 与迭代目标的关系 |
|---|---|---|---|
| 产品目标 | 产品长期要走向哪里 | 多个迭代或更长 | 迭代目标是其在单个迭代内的落地 |
| 迭代目标 | 本迭代要达成什么结果 | 一个迭代 | 自身 |
| Sprint Backlog | 为达成目标要做哪些工作 | 一个迭代 | 支撑迭代目标的待办与计划 |
| 产品待办 | 有哪些需求、优先级如何 | 跨迭代持续维护 | 迭代目标的选取来源 |
| 团队任务清单 | 谁负责完成哪些动作 | 个人当日或数日 | 支撑待办的执行分解 |
常见例子与误解
合格的迭代目标通常指向可观察的结果，并带有明确的完成标志。例如：“本迭代让订单列表页在弱网环境下的首屏加载时间降到两秒以内”“本迭代完成退款申请的自助提交，覆盖主要退款场景并通过验收”“本迭代把新用户注册流程的放弃率降低到约定水平”。这些写法都说明了要解决什么问题、交付什么结果，团队可以据此判断工作是否在推进目标。
常见误解之一是把任务清单当目标。例如把迭代目标写成“完成登录模块开发、完成支付接口联调、完成三个页面改版”。这类表述罗列了动作，却没有说明这些动作共同指向什么结果，团队在范围调整时缺少判断依据，任务做完也难以判断目标是否真正达成。修正方式是追问“这些任务完成后，用户或业务上会有什么变化”，把答案写成目标陈述，任务则作为支撑待办。
常见误解之二是把未完成工作默认结转。有些团队在迭代结束时，直接把未完成的事项原样挪入下一迭代，不做重新评估。这样做会让下一迭代的目标被历史遗留工作挤占，团队对承诺的重视程度下降，迭代目标逐渐退化为形式。正确做法是在评审或回顾中逐项评估未完成工作的价值与优先级，再决定是否纳入后续迭代。
这两类误解带来的影响是相似的：迭代目标失去约束范围取舍的作用，规划变成任务分配，跟进失去对齐基准，回顾也缺少可检验的结果。把目标写成结果、把未完成工作当作需要重新决策的事项，迭代目标才能在整个迭代周期中持续发挥参照作用。
常见问题
迭代目标必须用一句话写清楚吗？
一句话的目标陈述便于团队共同引用和记忆，但关键不在于字数，而在于它是否指向可观察的结果。如果一句话难以说清，可以用简短段落描述目标结果和完成标志，再列出支撑待办。需要避免的是把目标写成任务罗列，那样即使只有一句话，也失去了约束范围取舍的作用。
迭代进行中接到紧急需求，可以调整迭代目标吗？
可以调整，但应当作为一次明确的范围决策来处理。团队需要判断新需求是否服务于当前迭代目标：如果服务于目标且容量允许，可以纳入并同步更新支撑待办；如果不服务于目标，应放入产品待办等待后续评估。若新需求重要到必须插入，团队应同时移出等量的原有工作，保持目标与容量匹配，而不是简单叠加。
迭代目标没达成，团队应该怎么处理？
首先在评审或回顾中对照目标陈述确认哪些结果已交付、哪些未交付，分析偏差来自范围变化、容量估计还是执行障碍。未完成的工作逐项重新评估价值和优先级，再决定是否纳入后续迭代。目标未达成本身是改进输入，重点是把原因转化为下一迭代规划时的调整依据，而不是直接延续原目标。
团队容量不足时，迭代目标应该缩减还是拆分？
优先缩减目标范围，使目标与团队在一个迭代内实际能完成的工作量匹配。如果目标本身包含多个可独立交付的结果，也可以拆分为多个迭代分别达成。需要避免的是保留原目标陈述却只完成部分待办，这会让目标与支撑工作脱节，评审时难以判断达成情况。
使用工具管理迭代目标时，需要关注哪些记录动作？
工具层面主要承载三类记录：规划时将需求与任务规划至迭代并分配负责人；迭代中用看板同步任务状态、在站会上对齐进度与风险；迭代结束后借助报表复盘进度、质量和成本偏差。ONES 可以支持这些管理动作的记录与呈现，迭代目标本身的约定仍由团队在规划会议中完成。
