迭代规划是把需求池中已具备进入条件的条目，按优先级和团队产能转化为一个有明确迭代目标、可交付范围、任务拆分与承诺边界的短期计划。一次可执行的规划通常经过四步：确认输入、定目标圈范围、拆任务定角色、开会确认承诺。规划结果需要落到工作项和迭代视图中持续跟踪，ONES 可承接这一环节。
要点总览（TL;DR）
- 规划前先备齐四类输入：已排序且有验收标准的需求、扣除支持性工作后的可用产能、已知依赖与约束、上一迭代遗留项的重新评估结论；缺口项明确责任人和补齐时间。
- 迭代目标用一句话写清对象和可观察的完成标志，范围分承诺项与缓冲项两档，承诺项估算加总后与可用产能显式对照，超载时先砍缓冲项再按目标贡献度调整承诺项。
- 任务拆到一到三天可完成的粒度，每个任务有负责人、估算和完成定义；产品负责人在范围与优先级上拍板，开发与测试判断可行性与工作量，团队负责人保证过程留痕。
- 未完成条目在下个迭代重新评估，不默认自动结转；迭代内插入需求需满足准入条件并等量替换，任何范围变更都要记录对迭代目标的影响。
- 规划会结束后用目标、范围、任务、角色、记录五类检查项逐项核对，全部通过才进入执行，规划结果落到同一迭代视图中跟踪。
迭代规划前要准备哪些输入
规划会开得顺不顺，很大程度上取决于会前材料是否就位。信息不全时开会，团队只能现场补背景，讨论容易滑向细节，最后靠感觉拍板。建议在会前由产品负责人牵头，把下面三类输入整理成一份清单，逐项标注“就绪”或“缺口”，缺口项明确补齐责任人和时间。
| 输入类别 | 合格标准 | 常见缺口 |
|---|---|---|
| 候选需求条目 | 已在需求池中排序；每条有验收标准；颗粒度足以判断能否进入迭代 | 优先级靠口头约定；验收标准缺失或写成“功能可用” |
| 团队可用产能 | 按人统计本迭代可用天数，扣除休假、培训、线上支持、值班等支持性工作 | 直接按满勤计算；忽略跨团队支援与临时任务 |
| 依赖与约束 | 列出外部接口、第三方交付、环境与合规审批等已知依赖及其时间点 | 依赖在开发中途才暴露；约束只存在于个别人脑中 |
| 上一迭代遗留事项 | 对未完成条目逐条给出重新评估结论：继续、拆分、退回需求池或关闭 | 默认全部带入新迭代，未重新判断优先级与必要性 |
这份清单的作用是给规划会设一道门槛：候选需求没有验收标准，就不进入范围讨论；产能没有扣除支持性工作，就不做承诺。上一迭代遗留事项要单独过一遍，重新评估的依据包括需求是否仍然有效、剩余工作量、以及是否被更高优先级事项替代。遗留项不是天然的新迭代范围，它和新需求站在同一起跑线上竞争产能。
迭代目标怎么定，范围怎么圈
迭代目标回答的是“这个迭代结束时，什么变化能说明我们做成了”。写法上建议用一句话，包含对象和可观察的完成标志，例如“完成订单退款流程的线上可用，客服可在后台自助发起退款并查到处理结果”。目标要能被验证，避免写成“推进退款相关需求”这类无法判断完成与否的表述。
目标确定后，再按优先级圈范围。推荐把范围分成两档：承诺项是团队对目标负责、必须交付的条目；缓冲项是优先级次之、在产能有余量时承接的条目。两档都写进迭代视图，但只有承诺项进入对外承诺。这样做的目的是让范围有弹性，同时不模糊责任边界。
范围与产能的匹配需要一个显式的判断动作：把承诺项的工作量估算加总，与扣除支持性工作后的可用产能对照。超载时的取舍顺序建议如下：
- 先砍缓冲项，缓冲项清空仍超载，再动承诺项。
- 承诺项内部按“对迭代目标贡献度”排序，贡献度最低的先移出。
- 存在强依赖的条目，评估能否拆出可独立交付的部分，保留部分交付。
- 以上仍无法收敛，回到目标层面讨论：缩小目标，或调整迭代周期与资源。
取舍结论要当场记录，写明移出了什么、为什么、去向是退回需求池还是下个迭代候选。这一步的产出是迭代目标陈述加承诺/缓冲两档范围清单，它是后续任务拆分的唯一依据。
任务拆分、估算与角色分工
范围条目确定后，进入拆分环节。拆分的目标是让每个任务有明确的负责人、可判断的完成状态和合理的粒度。粒度上，单个任务以一到三天可完成为宜；超过这个尺度继续拆，小于半天的工作可以合并到相邻任务中，避免任务清单变成流水账。
完成定义（DoD）要写在任务或需求上，写清楚“做到什么程度算完成”。对开发任务，通常包括代码提交与评审、自测通过；对测试任务，包括用例执行与缺陷回归；对需求整体，包括验收标准逐条通过。DoD 写得具体，验收时才有共同标准，减少“我以为做完了”的争议。
估算方式由团队自定，常见的是相对估算（故事点）或工时估算。无论选哪种，关键是与产能用同一口径对照：用故事点估算，就用历史迭代的平均完成点数做参照；用工时估算，就把任务工时加总与可用人天比较。ONES Project 提供任务工时统计，可用于估算任务持续时间，具体统计口径需按团队配置确定。
| 角色 | 规划中的职责 | 主要产出 |
|---|---|---|
| 产品负责人 | 提供已排序需求与验收标准；解释需求价值；确认范围取舍 | 候选需求清单、优先级结论、承诺/缓冲范围 |
| 开发人员 | 参与需求评审；拆分开发任务；给出估算与技术风险 | 开发任务清单、估算值、依赖与风险说明 |
| 测试人员 | 确认验收标准的可测性；拆分测试任务；评估测试环境与数据准备 | 测试任务清单、验收要点、环境准备事项 |
| 设计人员（如涉及） | 确认交互与视觉交付时间点，识别设计依赖 | 设计任务与交付节点 |
| 团队负责人/Scrum Master | 组织会议、控制议程、记录承诺与风险、跟踪缺口闭环 | 会议记录、承诺清单、风险与依赖台账 |
角色分工的重点是让每个任务都有明确的责任人，而不是让所有角色都参与所有讨论。产品负责人在范围与优先级上拍板，开发与测试在可行性与工作量上给出判断，团队负责人保证过程完整、结论留痕。
规划会怎么开：议程与承诺确认
规划会建议控制在两小时以内（两週迭代），用时间盒约束讨论深度。会前把输入清单和候选范围发给参会人预读，会上不再重复介绍背景，直接进入决策。一个可用的议程如下：
| 环节 | 时长参考 | 内容与产出 |
|---|---|---|
| 目标确认 | 10–15 分钟 | 产品负责人说明迭代目标与候选范围，团队确认目标可检验 |
| 需求评审 | 30–40 分钟 | 逐条过承诺项，确认验收标准、依赖与疑问，疑问当场指派跟进人 |
| 任务拆分与估算 | 40–50 分钟 | 开发、测试分别拆分任务并估算，识别技术风险 |
| 产能对照与取舍 | 15–20 分钟 | 加总估算与可用产能对照，按约定顺序调整范围 |
| 承诺确认 | 10 分钟 | 团队逐项确认承诺项，记录风险、依赖与假设 |
承诺确认不是主持人宣布结论，而是团队每个成员对自己承接的任务明确表态。确认时同步记录三类信息：已识别的风险及其应对、外部依赖及需要谁在什么时间点提供、以及规划时做出的假设（例如“测试环境在第三天可用”）。假设一旦不成立，就要触发范围重议。
会议产出包括：迭代目标、承诺项与缓冲项清单、任务清单（含负责人、估算、DoD）、风险与依赖记录。这些内容会后同步给团队之外的干系人，例如业务方与管理层，同步范围以承诺项为主，缓冲项作为参考信息。
未完成工作与迭代中的变更怎么处理
迭代执行中出现未完成工作和新增需求是常态，处理规则要在规划时就约定好，而不是事后临时决定。核心原则是：未完成条目在下个迭代重新评估，不默认自动结转。
重新评估的判断依据包括：需求是否仍然有效、剩余工作量多少、优先级是否被新事项超越、以及未完成的原因（估算偏差、依赖阻塞还是范围蔓延）。评估结论有四种去向：继续进入下个迭代、拆分后部分继续、退回需求池等待重排、关闭。把结论写进遗留项记录，下个迭代规划时作为输入之一。
迭代内插入需求需要设准入条件，建议至少满足其一：影响线上稳定或数据安全；承诺项因外部依赖失效需要替换；业务方确认以等量替换的方式调整范围。替换规则是“进一个出一个”，插入项进入承诺范围的同时，把等量的原承诺项移入缓冲或退回需求池，保持总范围与产能匹配。
任何范围变更都要记录对迭代目标的影响：目标是否仍然成立、完成标志是否需要调整。如果变更导致目标无法达成，应尽早向干系人说明，而不是等到迭代结束才暴露。变更记录与目标影响说明，是迭代复盘时判断规划质量的重要材料。
一个两週迭代的规划示例
以下为演示情景，用于说明前述步骤如何连贯应用，不作为真实案例引用。
输入。某团队负责一个内部工单系统，两週迭代，团队 5 人（开发 3、测试 1、设计 0.5、产品 0.5）。本迭代可用产能扣除一人三天休假和每人约一天的支持性工作后，约为 38 人天。需求池中已排序的候选条目包括：工单批量导出（高）、工单超时提醒（高）、工单分类统计报表（中）、移动端适配（低）。上一迭代遗留“工单搜索优化”，剩余约两天工作量，重新评估后确认仍然有效，作为候选参与竞争。
目标与范围。迭代目标定为：“客服可在工单列表批量导出数据，超时工单在列表中有醒目标识并触发提醒。”承诺项为批量导出、超时提醒、搜索优化收尾；缓冲项为分类统计报表；移动端适配退回需求池。承诺项估算合计约 34 人天，留出约 4 人天余量应对风险。
任务拆分与分工。批量导出拆为后端导出接口、前端导出入口与进度提示、导出权限校验、测试用例设计与执行四个任务，分别由两名开发与测试承接，DoD 写明“导出文件字段与列表一致、万级数据量下不超时、权限校验覆盖三种角色”。超时提醒拆为超时规则配置、提醒触发与列表标识、通知渠道联调、测试验证。搜索优化收尾由原负责人继续，剩余任务重新估算为一天半。
取舍与依赖。分类统计报表依赖数据组提供新的统计口径，数据组确认本迭代内无法交付，因此该条目留在缓冲项且不承诺。超时提醒依赖消息通道的配置权限，规划时记录为风险，指定团队负责人在迭代第二天前确认权限到位；若未到位，触发范围重议，优先保障批量导出。
承诺确认。会上团队逐项确认承诺项，测试人员提出导出功能的测试数据准备需要提前一天，纳入任务清单。会议记录同步给业务方，明确承诺范围为三项，分类统计报表列为下个迭代候选。
规划完成后怎么检查是否合格
规划会结束不等于规划完成。用下面这份清单逐项核对，全部通过才进入执行；任一项不通过，明确返工内容与责任人。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 目标 | 迭代目标是否为一句话且可检验 | 能指出完成标志，团队对“做成什么样”理解一致 |
| 范围 | 承诺项与缓冲项是否分档清晰 | 承诺项有明确清单；超载取舍有记录；遗留项有重新评估结论 |
| 任务 | 每个承诺项是否拆到可执行粒度 | 任务有负责人、估算与 DoD；估算加总与产能对照过 |
| 角色 | 各角色职责与产出是否明确 | 产品、开发、测试的交付物可对应到具体条目；风险与依赖有跟进人 |
| 记录 | 会议结论是否留痕并同步 | 目标、范围、任务、风险、假设均有记录；同步对象与范围明确 |
需要返工的典型情形包括：承诺项估算明显超过可用产能却未做取舍；验收标准缺失仍进入承诺范围；依赖没有跟进人和时间点；遗留项未经评估直接带入。这些情形说明规划还停留在任务罗列层面，需要回到对应步骤补齐。
规划结果要落到协作工具中才能被持续跟踪。在 ONES 中，产品负责人可根据需求优先级将需求池中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪；需求与相关任务可分配负责人，迭代执行中通过敏捷看板管理任务状态。规划完成后，承诺项、缓冲项、负责人与风险记录都在同一迭代视图中，日常站会和进度跟进直接以此为准，减少计划与执行两张皮的情况。工具的具体功能范围与套餐差异，以实际使用版本为准。
常见问题
迭代规划会开完了，但团队对承诺项的理解还不一致，怎么办？
这通常说明承诺确认环节只做了主持人宣布，没有让每个成员对自己承接的任务表态。补救办法是把承诺项逐条过一遍，每条确认三件事：负责人是谁、完成定义写到什么程度、依赖由谁在什么时间点提供。确认过程中发现的疑问当场指派跟进人，并把结论写进会议记录。
如果分歧集中在验收标准上，说明输入阶段就没准备好，应把该条目退回需求池补齐验收标准，而不是带着模糊标准进入执行。承诺项清单以团队逐项确认后的版本为准，会后同步给干系人时也以此为准。
团队产能经常估不准，规划时应该按满产能还是打折计算？
建议按扣除支持性工作后的可用产能计算，而不是满勤天数。具体做法是按人统计本迭代可用天数，扣掉休假、培训、线上支持、值班等已知占用，再留出一小部分余量应对临时事项。余量留多少由团队根据历史情况定，没有统一比例。
估算口径要与产能口径一致：用故事点估算，就参照历史迭代的平均完成点数；用工时估算，就把任务工时加总与可用人天比较。连续几个迭代记录计划与实际完成的差距，下一轮规划时用这个差距修正产能判断，比一次拍准更现实。
迭代中途业务方要求插入一个紧急需求，一定要替换掉原有承诺项吗？
是否替换取决于插入项是否满足准入条件。建议规划时就约定至少满足其一才受理：影响线上稳定或数据安全；承诺项因外部依赖失效需要替换；业务方确认以等量替换方式调整范围。满足条件的，按“进一个出一个”处理，把等量的原承诺项移入缓冲或退回需求池，保持总范围与产能匹配。
不满足准入条件的，进入需求池等待下个迭代排序。无论哪种情况，都要记录这次变更对迭代目标的影响：目标是否仍然成立、完成标志是否需要调整。如果变更导致目标无法达成，尽早向干系人说明，不要等到迭代结束才暴露。
上一迭代没做完的条目，可以直接放进新迭代继续做吗？
可以继续做，但要先经过重新评估，不能默认自动结转。评估依据包括：需求是否仍然有效、剩余工作量多少、优先级是否被新事项超越、以及未完成的原因属于估算偏差、依赖阻塞还是范围蔓延。评估结论有四种去向：继续进入下个迭代、拆分后部分继续、退回需求池等待重排、关闭。
遗留项和新需求站在同一起跑线上竞争产能，评估结论写进遗留项记录，作为下个迭代规划的输入之一。这样做的目的是避免旧条目靠惯性占用产能，把团队资源压在已经不重要的事情上。
规划结果怎么在协作工具里落地，才能在日常跟进中直接用？
关键是让目标、承诺项、缓冲项、负责人和风险记录都落在同一个迭代视图里，站会和进度跟进直接以此为准。在 ONES 中，产品负责人可根据需求优先级将需求池中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪；需求与相关任务可分配负责人，迭代执行中通过敏捷看板管理任务状态。
工具的具体功能范围与套餐差异，以实际使用版本为准。规划落地后，日常跟进重点看承诺项的完成状态和风险跟进人的进展，缓冲项作为产能有余量时的参考信息。
