制定迭代计划，核心是把迭代目标转化为一组可交付、可估算、可验收的工作项，并在团队容量约束下形成承诺。做到什么程度算完成？需要产出四样东西：一句话迭代目标、明确的承诺范围、拆到任务级的工作项与估算、风险与依赖清单。本文按六个步骤展开操作流程，说明产品负责人、迭代负责人和团队成员各自的动作与交付物，给出一个两週迭代的完整示例，最后提供未完成项处置规则和计划完成检查清单。
要点总览（TL;DR）
- 迭代计划的核心产出是四项：一句话迭代目标、承诺范围、任务与估算、风险与依赖清单；四项齐备且可核验，计划才算完成。
- 制定流程分六步：定目标与时间盒、挑候选条目补验收条件、拆任务估算、核对容量与依赖、确定承诺范围留缓冲、确认计划并约定跟踪机制。
- 产品负责人对目标与验收条件负责，迭代负责人组织计划活动并核对容量与风险，团队成员负责拆分任务、给出估算和识别技术依赖。
- 承诺范围要落在扣除假期、会议和支持事务后的可用容量之内，并预留一到两成缓冲；超出部分明确排除并告知相关方。
- 迭代结束时未完成项需重新评估目标相关性、估算和优先级后再决定是否进入下个迭代，不默认整体结转。
迭代计划要产出什么：目标、范围与承诺
迭代计划是一份团队对“这两週交付什么、为什么交付、怎么交付”的共同约定。排期表只回答“谁什么时候做什么”，迭代计划还要回答“为什么做这些、做到什么算完成、哪些不做”。判断计划是否完成，看四项产出是否齐备且可核验。
| 产出 | 内容要求 | 判定标准 |
|---|---|---|
| 迭代目标 | 一句话说明本迭代要达成的业务或用户结果 | 团队能复述；目标可通过本迭代交付物验证；不把“完成若干需求”直接当目标 |
| 承诺范围 | 本迭代承诺交付的待办条目清单 | 每条有验收条件；总量与团队容量匹配；范围外条目明确排除 |
| 任务与估算 | 承诺条目拆分后的任务清单及工作量估算 | 任务粒度可在两三天内完成；估算有参照依据；研发、测试任务均已覆盖 |
| 风险与依赖清单 | 外部依赖、技术不确定性、人员可用性变化 | 每条有负责人和应对动作；高影响依赖在计划阶段已确认时间点 |
迭代目标与待办池条目是两类东西。待办池条目描述“要做的功能或修复”，迭代目标描述“做完之后带来什么变化”，例如“新用户注册流程可独立完成并进入试用”比“完成注册模块三个需求”更能指导取舍。目标确定后，待办条目才有筛选依据：与目标直接相关的优先进入候选，关联弱的留到后续迭代。
承诺范围与容量的关系需要提前算清。容量是团队在本迭代内实际可投入的工作量，要扣除假期、会议、支持性事务和已有承诺。承诺范围应控制在容量之内并留出缓冲，通常预留一成到两成用于应对估算偏差和临时插入。时间盒一般按团队既有节奏确定，两週是常见选择；时间盒一旦确定，计划活动、评审和回顾都围绕它安排，避免中途拉长。
制定迭代计划的六个步骤
六个步骤按顺序执行，每一步都有明确输入、动作、输出和完成标志。计划会议之前完成前三步的准备，会议中集中处理第四到第六步，可以把会议控制在两小时左右。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、确定迭代目标与时间盒 | 产品方向、上个迭代复盘结论 | 结合产品阶段和上轮问题，写出一句话目标；确认本迭代起止日期 | 一句话迭代目标、时间盒 | 目标可被交付物验证，团队对时间盒无异议 |
| 二、挑选候选条目并补充验收条件 | 已排序的待办池、迭代目标 | 按目标相关性挑选候选条目，逐条补充可验证的验收条件 | 候选条目清单及验收条件 | 每条候选都有验收条件，且能说明与目标的关联 |
| 三、拆分任务并估算工作量 | 候选条目、验收条件 | 按设计、开发、测试拆分任务，团队共同估算 | 任务清单与估算 | 任务粒度合理，估算由执行者给出并达成一致 |
| 四、核对容量、依赖与假期 | 任务估算、人员可用性、外部依赖信息 | 汇总可用人力，扣除假期与支持事务；逐条确认外部依赖的时间点 | 容量核算结果、依赖清单 | 估算总量与可用容量可比对，关键依赖有确认结论 |
| 五、确定承诺范围并预留缓冲 | 容量核算结果、候选条目优先级 | 按优先级装入容量，留出一到两成缓冲；明确排除项 | 承诺范围、缓冲说明 | 承诺范围在容量内，排除项已告知相关方 |
| 六、计划确认与迭代中跟踪调整 | 承诺范围、任务清单、风险清单 | 向相关方确认计划；迭代中按看板跟踪，出现偏差时调整范围而非 silently 加班 | 确认后的迭代计划、跟踪机制 | 相关方知悉承诺范围；跟踪节奏和调整规则已约定 |
第三步的估算要由实际执行任务的人给出，产品负责人和迭代负责人可以提供参照但不宜代填。估算单位可以是理想人天或故事点，关键是团队内部口径一致，并与历史数据可比对。第四步核对容量时，把“名义人力”换算成“可用人力”：五人团队两週名义上是五十人天，扣除假期、会议和支持事务后可能只有三十五人天左右，这个数字才是承诺范围的边界。
第六步的跟踪机制在计划阶段就要约定：每日站会对齐进度与阻塞，看板反映任务状态，出现范围偏差时由产品负责人和迭代负责人共同决定缩减范围还是调整目标。计划确认后，把迭代目标、承诺范围、任务清单和风险清单放在团队都能看到的位置，作为后续评审和回顾的依据。
角色分工与各自交付物
计划制定涉及三类角色，职责边界清晰才能避免“目标没人定、估算没人认、依赖没人跟”。产品负责人对“做什么、为什么做”负责，迭代负责人对“计划活动组织与执行跟踪”负责，团队成员对“怎么拆、做多久、有什么技术依赖”负责。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 产品负责人 | 维护待办池优先级；确认每条候选的验收条件；对迭代目标负责；在范围需要调整时做取舍 | 迭代目标、候选条目及验收条件、范围调整决定 |
| 迭代负责人 | 组织计划活动；汇总容量并核对假期与支持事务；跟踪进度与风险；主持站会和回顾 | 容量核算结果、风险与依赖清单、跟踪记录 |
| 团队成员 | 拆分任务；给出估算；识别技术依赖和不确定性；在迭代中更新任务状态 | 任务清单、估算结果、技术依赖说明 |
计划会议的参与角色包括产品负责人、迭代负责人和全体执行成员，必要时邀请依赖方代表参加依赖确认环节。两週迭代的计划会议通常安排两小时：前一小时由产品负责人说明目标与候选条目、团队补充验收条件，后一小时集中拆分估算、核对容量并确认承诺范围。会议结束时应形成书面计划，而不是停留在口头共识。
当团队使用研发管理工具承载这套流程时，产品负责人可以把待办池中已排好优先级的需求规划到对应迭代，并在计划会议上与团队共同评审；对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可以用子任务把需求拆开，便于后续处理和跟踪。迭代过程中，团队围绕迭代目标完成各自拆解的任务，通过敏捷看板管理任务状态，在每日站会上借助看板对齐进度与风险；燃尽图可以帮助团队直观评估当前研发效率。迭代完成并发布后，回顾会可以结合燃尽图、工时日志等数据复盘进度、质量和成本偏差。这些能力在 ONES 敏捷研发管理方案中有对应说明，具体版本与配置需按实际使用环境确认。
一个两週迭代的计划示例
以下为演示情景，数字仅用于说明方法，不代表真实团队数据。背景：一个五人团队（两名后端、两名前端、一名测试），两週迭代，目标是“完成订单导出功能的上线准备，使运营可按条件导出并核对数据”。
第一步确定目标与时间盒。目标写为“运营可在后台按时间与状态导出订单，导出结果与列表数据一致”，时间盒为两週。上轮复盘提到“测试介入晚导致返工”，本迭代把测试任务提前排入计划。
第二步挑选候选条目。待办池中与目标相关的有三条：导出接口与权限控制、导出任务异步处理与进度提示、导出结果校验说明。关联较弱的“导出模板自定义”留到后续迭代。三条候选分别补充验收条件，例如“导出文件字段与列表一致，十万条以内十分钟完成”。
第三步拆分与估算。团队把三条候选拆成设计、开发、测试任务共十四项，估算合计约四十人天。第四步核对容量：五人两週名义五十人天，扣除一天假期、两天会议与支持事务，可用约三十八人天，另有前端一名成员后三天参与线上问题支持，实际可用约三十五人天。外部依赖包括数据平台提供导出字段字典，确认在迭代第三天交付。
第五步确定承诺范围。四十人天估算超出三十五人天容量，团队决定把“导出结果校验说明”中的自动化校验部分移出本迭代，保留人工核对说明，调整后估算约三十三人天，预留两人天缓冲。排除项和缓冲在计划确认时告知运营方。第六步确认与跟踪：计划会上形成目标、范围、任务清单和风险清单，风险包括字段字典延迟和十万条数据性能未验证，各指定负责人；迭代中每日站会对齐，若第三天字段字典未到位，由迭代负责人升级并评估是否缩减范围。
计划确认后的输出样例包括：一句话目标；承诺条目三条及验收条件；十四项任务及估算、负责人；容量核算说明（可用约三十五人天、承诺约三十三人天、缓冲两人天）；风险与依赖清单两条及应对动作。这份输出同时作为迭代评审和回顾的对照基准。
未完成工作如何处理与计划完成检查
迭代结束时未完成的工作项，处理原则是重新评估，而非默认结转到下一迭代。结转前要回答三个问题：该条目是否仍符合下个迭代目标；原估算是否仍然成立，是否需要重新拆分；优先级是否因新信息发生变化。三个问题都通过，才进入下个迭代的候选范围；否则退回待办池重新排序，或拆分后部分结转。直接把未完成项整体搬到下个迭代，会让承诺范围逐渐失真，也会掩盖估算偏差的原因。
计划制定完成后，用以下清单逐项检查：
- 迭代目标是一句话，且能通过本迭代交付物验证；
- 承诺范围内每条都有可验证的验收条件，范围外条目已明确排除；
- 任务已拆到两三天可完成的粒度，估算由执行者给出且口径一致；
- 容量核算扣除了假期、会议和支持事务，承诺总量在可用容量之内；
- 外部依赖已逐条确认时间点和负责人，技术不确定性已列入风险清单；
- 缓冲已预留并说明用途，相关方已知悉承诺范围与排除项；
- 跟踪节奏、看板状态规则和范围调整规则已约定。
检查不通过时按缺口返工：目标不可验证，回到第一步重写；验收条件缺失，由产品负责人补齐后再进入估算；估算与容量不匹配，回到第五步调整范围或补充人力；依赖未确认，由迭代负责人联系依赖方取得时间承诺后再确认计划。返工完成后重新走一遍检查清单，确认通过再对外承诺。
常见问题
迭代目标写成“完成某几个需求”可以吗？
可以写，但指导取舍的作用有限。“完成注册模块三个需求”描述的是工作量，团队在范围需要压缩时难以判断先砍哪一条。把目标写成可验证的结果，例如“新用户注册流程可独立完成并进入试用”，候选条目的取舍就有了依据：直接支撑这个结果的优先进入承诺范围，关联弱的留到后续迭代。目标确定后，再回头检查每条候选能否说明与目标的关联。
团队容量怎么算才算准？
先算名义人力，再换算成可用人力。五人团队两週名义上是五十人天，扣除假期、会议、支持性事务和已有承诺后，实际可用可能只有三十五人天左右，这个数字才是承诺范围的边界。核算时逐人核对可用天数，把外部依赖的等待时间也考虑进去。估算总量与可用容量放在一起比对，超出时调整范围，而不是把容量数字往上凑。
迭代进行中插入紧急需求，计划要不要改？
需要改，但要按计划阶段约定的规则改。常见做法是由产品负责人和迭代负责人共同判断：新需求是否比承诺范围内某条更贴近迭代目标，若是则明确移出等量的原承诺条目，并告知相关方；若否则放入待办池等待下个迭代。关键是保持承诺范围与容量匹配，避免只加不减导致计划失真。插入和移出的记录留到回顾会上分析原因。
未完成的工作项可以直接搬到下个迭代吗？
不建议整体直接搬。结转前先回答三个问题：该条目是否仍符合下个迭代目标；原估算是否仍然成立、是否需要重新拆分；优先级是否因新信息发生变化。三项都通过才进入下个迭代的候选范围，否则退回待办池重新排序，或拆分后部分结转。整体搬运会让承诺范围逐渐失真，也会掩盖估算偏差的真实原因。
计划会议开多久、哪些人必须参加？
两週迭代的计划会议通常安排两小时：前一小时由产品负责人说明目标与候选条目、团队补充验收条件，后一小时集中拆分估算、核对容量并确认承诺范围。参与角色包括产品负责人、迭代负责人和全体执行成员，涉及外部依赖时邀请依赖方代表参加确认环节。会议结束时应形成书面计划，包含目标、承诺范围、任务清单、估算和风险清单，不停留在口头共识。
