迭代计划要落到可执行，关键在四个条件：一个可验证的迭代目标、按可用人天和历史速率算出的容量、从已排序需求中选出的Sprint Backlog，以及迭代中范围调整和未完成工作的处理规则。本文按“定目标—算容量—选条目—拆任务—确认承诺—设跟进与调整规则”六步展开，给出每步的输入、动作与输出，并附角色分工、两周迭代示例和完成检查清单。迭代目标、Sprint Backlog与任务拆分可以在ONES中承载，后文在相应环节说明衔接方式。
要点总览（TL;DR）
- 迭代计划按六步完成：定目标、算容量、选条目、拆任务、确认承诺、设跟进与调整规则，每步都有明确输入与输出。
- 容量用可用人天结合最近几个迭代的实际速率估算，取偏保守区间；Sprint Backlog从已排序需求顶部依次选取，累计不超过容量。
- 产品负责人交付迭代目标与优先级，Scrum Master维护会议规则与调整流程，开发团队负责估算、拆分任务并给出承诺。
- 迭代中新增需求走替换而非追加；未完成条目回到待办重新评估排序，不默认自动结转，速率只统计实际完成部分。
- 计划完成后用目标与容量一致性、任务负责人与完成标准、依赖风险登记、跟进调整规则四项逐条核对。
迭代计划的核心答案与六步操作
迭代计划的产出是一份团队共同认可、当天就能开工的安排。它由六个动作串成，前一步的输出是后一步的输入，任何一步缺失都会让计划在执行中变形。
第一步：定目标。输入是产品负责人对本次迭代业务价值的判断和上一迭代的遗留问题。动作是把目标写成一句可验证的话，包含对象、期望变化和验证方式，例如“让新用户完成首次配置的步骤从五步减到三步，由可用性测试确认”。输出是一句话迭代目标。完成标志是团队能复述这个目标，并说清迭代结束时用什么证据判断它达成。
第二步：算容量。输入是团队人数、迭代内可用工作日、请假与支持性事务占用、上一到三个迭代的实际完成速率。动作是先算可用人天：迭代工作日乘以人数，扣除休假、培训、值班和例行维护；再对照历史速率，取一个偏保守的区间作为本次可承载的工作量。输出是容量数字和它的计算口径。完成标志是容量有明确来源，团队对“这次能做多少”有共同预期。
第三步：选条目。输入是已排好序、满足就绪标准的需求列表和上一步的容量。动作是从列表顶部依次选取条目，累计估算不超过容量，遇到依赖未就绪或验收标准不清的条目跳过并记录原因。输出是Sprint Backlog初稿。完成标志是每条入选条目都有估算、验收标准和优先级依据。
第四步：拆任务。输入是Sprint Backlog初稿。动作是把每条需求拆成可在一两天内完成的任务，每项任务写明负责人和完成标准；拆分粒度以“一个人能在一天内推进到可检查状态”为准，过大的任务继续拆，过小的合并。输出是带负责人和完成标准的任务清单。完成标志是每条任务都能回答“谁做、做完是什么样”。
第五步：确认承诺。输入是任务清单、依赖清单和风险记录。动作是在规划会上逐条过一遍入选条目，确认验收标准、任务拆分、依赖方和时间点，团队对目标与范围明确表态。输出是团队承诺的迭代计划。完成标志是没有人对某条任务的可行性保留意见却未记录。
第六步：设跟进与调整规则。输入是迭代计划和团队协作习惯。动作是约定每日跟进的方式与时间、进展和阻碍记录在哪里、范围调整由谁决策、按什么原则替换。输出是写进迭代说明的跟进规则。完成标志是团队知道遇到阻塞找谁、想加需求走什么路径。
在ONES中，产品负责人可以按优先级把产品待办列表中的需求规划到对应迭代，并在迭代计划会议上与团队共同评审；对本次迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可以用子任务把需求拆开，便于后续处理和跟踪。这对应第三步到第五步的承载方式。
规划会前要准备哪些输入
规划会开得顺不顺，多半取决于会前材料是否备齐。以下四项应在会议开始前完成，而不是在会上临时补。
- 已排序且满足就绪标准的需求条目。列表顶部的条目应具备清晰的描述、验收标准和估算；未就绪的条目不进入本次选取范围，产品负责人需提前标注。
- 上一迭代速率与团队可用人天。速率取最近几个迭代的实际完成量，可用人天按日历逐人核算，请假、培训、支持性事务单独列出，避免会上凭印象报数。
- 依赖与外部约束清单。列出需要其他团队、外部供应商或特定环境配合的条目，写明依赖方、需要的时间点和当前状态。
- 验收标准与完成定义。每条候选需求要有可检查的验收标准；团队层面的完成定义（例如代码评审、测试通过、文档更新）应提前确认，避免会上对“做完”理解不一。
这四项材料建议在会前一至两天发给参会人预读，会上直接进入确认和取舍，把时间留给估算分歧和依赖协调。
角色分工与各自交付物
迭代计划由三类角色共同完成，各自有明确的交付物，也有对应的决策边界。
| 角色 | 主要职责 | 交付物 | 范围调整中的决策权 |
|---|---|---|---|
| 产品负责人 | 确定迭代目标，维护需求优先级，说明业务价值与验收标准 | 一句话迭代目标、已排序的候选条目、验收标准 | 提出调整需求并说明价值；与团队协商替换哪条，不单方面追加范围 |
| Scrum Master | 组织规划会，维护会议规则与时间盒，跟踪阻碍的排除 | 会议议程与纪要、跟进与调整规则、阻碍清单 | 维护调整流程按约定执行，记录决策结果，不替团队做技术取舍 |
| 开发团队 | 估算容量与条目、拆分任务、确认可行性并作出承诺 | 容量计算、任务清单与负责人、迭代承诺 | 评估替换方案对容量的影响，决定技术上能否承接 |
分工的关键在于承诺由开发团队给出，产品负责人负责说明“为什么做这条”，Scrum Master负责让规则被遵守。范围调整时，三方按同一口径处理：产品负责人提出，团队评估容量影响，Scrum Master记录结果，替换而非叠加。
一个两週迭代的完整示例
以下为演示情景，团队人数、速率和条目数量均为示例数字，用于说明六步如何落地，不代表真实案例。
容量计算。团队6人，两週迭代共10个工作日，合计60人天。扣除年假4人天、培训2人天、例行值班与支持6人天，可用约48人天。最近三个迭代实际完成分别为42、45、40人天，取偏保守的40人天作为本次可承载工作量。
迭代目标。“让新用户完成首次配置的步骤从五步减到三步，由可用性测试的5名用户确认。”目标包含对象、变化和验证方式，迭代结束时可以判定。
Sprint Backlog与任务拆分。从已排序列表顶部选取三条需求，估算合计38人天，留出少量余量：
| 需求 | 估算 | 任务拆分示例 | 负责人 |
|---|---|---|---|
| 配置流程合并为三步 | 20人天 | 梳理现有五步的字段依赖；设计三步流程原型；后端接口调整；前端页面改造；联调与自测 | 设计1人、前端2人、后端2人 |
| 配置进度提示 | 10人天 | 定义提示触发条件；组件开发；埋点与验证 | 前端1人、后端1人 |
| 可用性测试准备 | 8人天 | 招募5名测试用户；编写测试脚本；安排测试环境 | 设计1人、测试1人 |
迭代中的一次范围调整。迭代第5天，业务方希望加入一条“配置模板推荐”需求，估算6人天。团队评估后容量不足以承接，按替换原则处理：产品负责人确认该需求优先级高于“配置进度提示”，团队将后者移出本次迭代，替换为模板推荐，Scrum Master记录调整原因和决策人。迭代范围总量保持不变。
迭代结束的处理。迭代末，“可用性测试准备”中的测试环境安排未完成。该条目回到待办列表，由产品负责人重新评估优先级后重新排序，不默认自动带入下一迭代。团队在回顾中核对速率时，按实际完成的条目统计，未完成部分不计入本次速率。
迭代过程中，团队成员围绕迭代要完成的需求推进自己拆解的任务，并通过敏捷看板管理任务状态；每日站立会议可以借助看板对齐进度与风险、排除问题，燃尽图则用于观察剩余工作量与效率变化。这些环节在ONES中对应看板与燃尽图的跟进方式。
未完成工作与范围调整的处理规则
迭代计划的可信度，取决于变更是否有规则。两条原则需要提前写清楚：范围调整走替换，未完成工作重新评估。
范围调整的替换原则。迭代开始后新增需求，须由产品负责人提出并说明业务价值，团队评估容量影响；容量不足时，移出等量的低优先级条目，保持总量不变。决策口径建议明确到人：产品负责人决定价值排序，开发团队确认技术可行性，Scrum Master记录调整时间、原因和结果。未经替换的追加不进入本次迭代。
未完成条目的重新评估步骤。迭代结束时，逐条核对未完成条目：确认已完成部分和剩余工作；重新估算剩余工作量；判断验收标准是否仍然有效；由产品负责人结合最新优先级决定它回到待办列表的位置。回到待办后按正常排序参与下一次选取，不因“上次没做完”自动获得优先位置。
对速率统计的影响。速率按迭代内实际完成的条目统计，未完成条目不计入。这样速率反映的是团队稳定交付的能力，而不是承诺了多少。若连续多个迭代出现较多未完成条目，应在回顾中检查容量估算口径和任务拆分粒度，而不是简单调高速率数字。
迭代计划的完成检查
计划制定完成后，用以下清单逐项核对。全部通过，说明这份计划具备执行条件；有未通过项，应在规划会结束前补齐或记录为风险。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 目标、容量、条目是否一致 | 迭代目标能否由入选条目支撑；条目估算合计是否在容量范围内 | 目标有对应条目，总量不超过容量，留有余量 |
| 任务是否有负责人与完成标准 | 每条任务是否写明负责人、完成标准和大致工作量 | 无无主任务，无“做完再说”的模糊标准 |
| 依赖与风险是否已登记 | 外部依赖的依赖方、时间点和状态是否记录；主要风险是否有应对人 | 依赖清单完整，风险有明确跟进人 |
| 跟进与调整规则是否已约定 | 每日跟进的时间与方式、进展记录位置、范围调整的决策人和替换原则 | 团队能说清遇到阻塞找谁、加需求走什么流程 |
这份清单也可以在迭代中期复查一次，用来判断计划是否仍成立。迭代完成并发布后，可结合燃尽图、工时日志等数据在回顾会上复盘进度与偏差，把容量口径和拆分粒度的改进带入下一次计划。
常见问题
团队没有历史速率数据，第一次迭代的容量怎么估？
没有历史速率时，可以先用可用人天作为上限，再按经验打一个折扣，例如按可用人天的六到七成安排条目，留出估算偏差和临时事务的空间。第一个迭代结束后，用实际完成的条目量作为初始速率，之后取最近两到三个迭代的完成量做参考。关键是记录本次容量的计算口径，让下一次估算有据可依，而不是凭印象报数。
迭代进行到一半，业务方坚持要加需求，团队应该怎么处理？
按替换原则处理：由产品负责人说明新需求的业务价值，团队评估它占用的容量，容量不足时移出等量的低优先级条目，保持迭代总量不变。如果新需求优先级确实更高，替换是合理选择；如果无法移出任何条目，就把它放入待办列表等待下一次迭代。Scrum Master记录调整时间、原因和决策人，便于回顾时核对范围变化对进度的影响。
未完成的需求可以直接带到下一个迭代吗？
建议重新评估后再安排，而不是默认带入。迭代结束时逐条核对未完成条目：确认已完成部分和剩余工作，重新估算剩余工作量，检查验收标准是否仍然有效，再由产品负责人结合最新优先级决定它回到待办列表的位置。这样做的目的是让下一次选取基于当前价值判断，避免旧条目因为“上次没做完”长期占据容量。
每日跟进需要记录到什么程度，才不会变成额外负担？
每日跟进围绕三件事记录即可：昨天推进了哪些任务、今天计划推进哪些、遇到什么阻碍以及需要谁协助。记录落在任务状态和阻碍清单上，不必写成长篇日报。团队可以借助敏捷看板对齐进度与风险、排除问题，让状态更新和站会讨论使用同一份信息。跟进规则应在迭代开始时约定，包括时间、时长和记录位置，避免每天临时决定。
迭代计划制定完成后，什么情况下需要重新调整？
常见触发条件有三类：关键依赖方延期导致某条需求无法按期推进；迭代中期发现某条需求的估算明显偏低，剩余工作量超出容量；业务优先级发生重大变化。出现这些情况时，按约定的调整流程处理，由产品负责人提出、团队评估容量影响、Scrum Master记录结果。小幅波动在每日跟进中消化，涉及范围增减的调整走替换原则，并在迭代说明中留下记录。
