迭代计划与Sprint Backlog常被混用，实际分工不同：迭代计划回答这个迭代“做什么、做到什么程度、怎么协同”，Sprint Backlog承载承诺工作拆解后的任务、负责人、估算与状态。两者在内容范围上一粗一细，形成时机上一先一后，更新方式上一个受控调整、一个持续更新。本文围绕具体迭代运行，说明两者的区别、联系与常见误解。
要点总览（TL;DR）
- 迭代计划是对一个迭代“做什么、做到什么程度、怎么协同”的整体安排，Sprint Backlog 是承载该迭代承诺工作的细化任务清单，前者定方向和边界，后者定任务和进度。
- 内容范围上，迭代计划覆盖目标、范围取舍、交付预期与协同安排；Sprint Backlog 覆盖拆解后的任务、负责人、估算与状态，一项范围通常对应多条任务。
- 形成时机上，迭代计划在迭代启动前的规划活动中形成，Sprint Backlog 在计划确定后由待办事项拆解形成；计划调整时，先确认目标或范围变化，再调整任务清单。
- 更新方式上，迭代计划在目标或范围变化时受控调整，Sprint Backlog 在执行中随任务进展持续更新；迭代结束时未完成工作需重新评估，而非默认结转。
- 两者服务于同一迭代目标，构成“计划给出输入、拆解产生任务、执行更新状态、评审形成反馈”的执行链，产品 Backlog 则属于需求池管理，为多个迭代提供候选需求。
迭代计划与Sprint Backlog分别指什么
迭代计划是对一个迭代的整体安排，核心内容包括迭代目标、从待办列表中选取并确认的范围、交付预期、验收标准，以及评审、测试、发布等关键协同安排。它回答的是“这个迭代为什么做、做到哪里算完成”，是团队对本次迭代形成共同承诺的载体。
Sprint Backlog是承载该迭代承诺工作的细化任务清单。它通常由产品待办事项拆解而来，逐条列出任务、负责人、估算和状态，回答的是“为了完成迭代目标，具体谁在做什么、做到哪一步”。
一句话区分：迭代计划定方向和边界，Sprint Backlog定任务和进度。前者是迭代的“安排”，后者是安排落地后的“工作清单”。在敏捷迭代运行中，两者前后衔接：计划会议产出迭代目标与范围，团队据此拆解任务形成Sprint Backlog，执行期间以清单进展支撑计划判断。
内容范围的区别：整体安排与细化任务清单
两者的内容差异主要体现为颗粒度和覆盖范围不同。迭代计划处于较粗的层面，覆盖目标、范围取舍、交付预期和协同安排；Sprint Backlog处于较细的层面，覆盖拆解后的任务、负责人、估算和状态。粗颗粒的计划为细颗粒的清单提供依据，细颗粒的清单让粗颗粒的计划可执行、可跟踪。
| 对比维度 | 迭代计划 | Sprint Backlog |
|---|---|---|
| 内容颗粒度 | 粗颗粒，以目标、范围、交付预期为主 | 细颗粒，以具体任务为单位 |
| 核心内容 | 迭代目标、范围取舍、交付预期、验收标准、协同安排 | 任务、负责人、估算、状态 |
| 只出现在这一方的典型内容 | 迭代目标表述、范围取舍理由、评审与发布安排 | 单条任务的工时估算、任务级状态流转 |
| 回答的问题 | 这个迭代做什么、做到什么程度 | 谁在做什么、进展如何 |
需要留意的是，迭代目标、范围取舍这类内容只属于迭代计划，不会出现在任务清单里；单条任务的估算和状态只属于Sprint Backlog，不必写进计划。两者内容有对应关系，但并非互相复制：计划中的一项范围，往往对应清单中的多条任务。
形成时机的区别：先定计划再落成清单
迭代计划在迭代启动前的规划活动中形成。产品负责人根据优先级把待办事项规划到对应迭代，团队在迭代计划会议上共同评审需求，就本次迭代要完成的内容与验收标准达成一致，形成迭代目标与范围。这一步的完成标志是团队对“做什么、做到什么程度”形成共识。
Sprint Backlog在计划确定之后形成。团队以已确认的迭代范围和验收标准为前提，把需求拆解为可执行的任务，明确负责人和估算，形成任务清单。拆解发生在计划之后，是因为任务需要围绕已确认的目标和范围展开，避免先拆任务再倒推目标。
当迭代计划发生调整时，先后关系同样成立：先确认目标或范围的变化，再相应增删、重排Sprint Backlog中的任务。顺序颠倒容易造成清单与计划脱节，出现任务做了但目标未覆盖，或目标已变而清单未动的情况。
更新方式的区别：受控调整与持续更新
迭代计划的更新是受控的。它通常在目标变化、范围需要取舍、关键交付预期调整或外部依赖发生重大变化时触发，由产品负责人与团队共同确认，并同步影响验收标准和协同安排。计划不宜频繁改动，否则团队难以形成稳定承诺；一旦调整，应留下明确的变更依据，让后续复盘有据可查。
Sprint Backlog的更新是日常且持续的。执行期间，团队成员围绕迭代要完成的需求推进自己拆解的任务，通过看板等方式更新任务状态；每日站立会议借助可视化看板对齐进度、识别风险、排除问题。任务粒度的增补、拆分和状态流转属于正常工作节奏，不需要每次都上升为计划变更。
未完成工作的处理需要单独说明。迭代结束时，未完成任务应重新评估：判断其是否仍符合下一迭代目标、优先级是否变化、估算是否需要修正，再决定是否纳入下一迭代。默认把未完成任务整体结转到下一迭代，会让清单不断膨胀、承诺逐渐失真，也不利于暴露计划与实际能力的差距。
两者的联系：目标一致、逐层落地
迭代计划与Sprint Backlog服务于同一个迭代目标，构成一条从安排到执行的链条。计划确定目标与范围，清单把范围分解为任务并落到人；清单的进展又反向支撑计划判断，团队据此评估目标能否达成、范围是否需要取舍、风险是否需要上报。
这条链条可以概括为：计划给出输入，拆解产生任务，执行更新状态，评审形成反馈，反馈再影响下一次计划。任何一个环节脱节，都会让迭代运行失去依据——只有计划没有清单，目标难以落地；只有清单没有计划，任务容易偏离方向。
在工具承载上，这条链条可以借助具体功能落地。例如在ONES中，产品负责人可按优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务拆分需求，便于后续处理和跟踪；执行阶段团队成员通过敏捷看板管理任务状态，并在每日站立会议中对齐进度与风险。这些动作分别对应计划形成、清单拆解和持续更新三个环节。
相邻概念区别：与产品 Backlog、敏捷框架的边界
产品Backlog属于需求池管理，是产品层面持续维护的待办事项集合，来源包括用户反馈、业务目标和各方诉求，按优先级排序，为多个迭代提供候选需求。Sprint Backlog只覆盖当前一个迭代已承诺的工作，范围更窄、时效更短。两者的关系是：产品Backlog是选材的来源，Sprint Backlog是本轮选中的材料被拆解后的执行清单。
在ONES中，可使用工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品Backlog，这属于需求池管理场景，与具体迭代运行区分开。迭代计划与Sprint Backlog则属于迭代层面的规划与执行。
敏捷框架层面的概念，如角色职责、事件安排、价值观等，归入敏捷项目管理的整体方法论，本文不展开。本文关注的是具体迭代运行中，计划与任务清单在范围、时机和更新上的边界，便于团队在日常协作中准确使用这两个概念。
具体例子与常见误解
以一个两周迭代为例。计划会议上，团队从产品Backlog中选取三项需求进入本迭代，确认迭代目标为“完成订单查询功能上线”，明确验收标准和测试安排，形成迭代计划。随后团队把三项需求拆解为若干任务，分别指派负责人、给出估算，形成Sprint Backlog。执行中，任务状态在看板上持续更新；若中途发现某项需求验收标准需要调整，先由产品负责人与团队确认计划变更，再同步调整对应任务。迭代结束时，一项任务未完成，团队重新评估其优先级和估算，决定是否放入下一迭代。
常见误解主要有三类：
- 把Sprint Backlog当成需求池。需求池面向多个迭代持续积累，Sprint Backlog只承载当前迭代的承诺工作，混用会导致范围失控。
- 把迭代计划当成任务清单。计划说明目标和范围，不逐条列任务；用计划代替清单，执行时缺少责任人和进度依据。
- 认为未完成任务会自动结转。未完成工作应重新评估后再决定是否纳入下一迭代，默认结转会掩盖计划偏差。
厘清这些边界后，团队在计划会议上聚焦目标与范围，在执行中聚焦任务与状态，迭代运行的节奏会更清晰。
常见问题
迭代计划会议开完，Sprint Backlog 是否必须当天全部拆完？
不必要求当天拆到最细。计划会议的核心产出是迭代目标、范围与验收标准的共识，任务拆解可以在计划确定后紧接着进行，也可以在执行初期继续细化。判断标准是：团队能否据此开始工作并跟踪进度。对于尚不清楚实现路径的需求，可以先拆出可执行的第一步，等方案明确后再补充后续任务。需要避免的是长期停留在粗颗粒状态，导致责任人和进度无从判断。
迭代执行到一半，发现范围需要缩减，应该先改计划还是先改任务清单？
先改计划。范围缩减属于迭代计划的变更，需要产品负责人与团队共同确认取舍理由、调整后的交付预期和验收标准，再据此增删或重排 Sprint Backlog 中的任务。顺序颠倒容易出现任务已删但目标仍写着原范围，或目标已缩而清单未动的情况，后续复盘时难以还原真实决策过程。
未完成的任务在迭代结束时重新评估，具体评估哪些内容？
至少评估三点：这项任务是否仍服务于下一迭代的目标；优先级相对其他候选需求是否发生变化；原估算是否因实际情况需要修正。评估后再决定是否纳入下一迭代，而不是整体平移。这样做的好处是让计划与实际能力的差距暴露出来，便于在后续计划中调整范围或投入。
Sprint Backlog 和产品 Backlog 在工具里需要分开维护吗？
两者管理对象不同，通常分开维护更清晰。产品 Backlog 是面向多个迭代持续积累和排序的候选需求集合，Sprint Backlog 只承载当前迭代已承诺的工作。在 ONES 中，产品负责人可按优先级将产品待办列表中的需求规划至对应迭代，团队再对当前迭代的需求做子任务拆分，执行中通过敏捷看板管理任务状态。产品 Backlog 的整理属于需求池管理场景，与具体迭代运行区分开。
任务粒度的增补和拆分，什么情况下需要上升为迭代计划变更？
判断依据是是否触及迭代目标、范围或验收标准。单纯把一项任务拆成两项、调整负责人、更新状态，属于 Sprint Backlog 的日常更新，不必走计划变更。若新增的任务意味着引入原范围之外的需求，或某项需求因故移出本迭代，则涉及范围取舍，应由产品负责人与团队确认计划变更，再同步调整任务清单。
