迭代规划要把“这一轮达成什么”转成“团队能做完、可验证的一批工作”。顺序是：先定迭代目标和验收口径，再核算真实可用容量，从已排序需求中选范围并拆成 Sprint Backlog，逐条确认完成定义与依赖，最后在规划会上对齐承诺并约定范围调整规则。本文按这七步展开，并说明目标、容量表、Backlog、依赖风险清单和调整规则如何在 ONES 中承载。
要点总览（TL;DR）
- 迭代规划按“定目标与验收口径→算容量→选范围拆Backlog→开规划会形成承诺→约定范围调整规则→会后检查”的顺序推进，每一步都有明确输入和产出。
- 容量用可用人天与近三到五轮历史速率交叉校验，取偏保守值并预留约一成计划外余量，范围装到上限即停。
- Sprint Backlog 每条需含验收要点、估算、负责人和依赖标注，粒度以本轮内能完成并验证为准，高价值与高风险条目优先。
- 迭代中变更优先采用换入换出，未完成条目在迭代结束时重新评估价值、拆分与优先级，不做默认结转。
- 规划质量在评审与回顾中用承诺完成比例、变更次数与原因、依赖阻塞时长检验，并作为下一轮规划的修正输入。
迭代规划要先定什么：目标、范围与验收口径
规划会之前，团队需要先拿到三样输入：一份已排序、颗粒度足够的需求列表，上一轮遗留且已重新评估的条目，以及本轮的依赖和外部约束（例如第三方接口上线时间、关键人员请假、合规评审窗口）。缺少这些输入，规划会容易变成任务分派会：主持人逐条念需求，成员被动认领，散会后没人说得清这一轮到底要验证什么。
迭代目标怎么写
迭代目标用一句话写清“为谁解决什么问题、达到什么可观察的结果”，再补一到三条验收结果。写法上避免“完成某某模块开发”这类只描述动作的表述，改为描述用户或业务侧可观察的变化。例如：“让新注册用户在不看帮助文档的情况下完成首次下单”，验收结果是“可用性测试中 5 名用户至少 4 名独立完成”“下单主流程接口成功率在预发环境达到约定阈值”。目标数量控制在一个，最多两个；目标过多等于没有优先级。
验收口径与完成定义在规划前确认
验收口径针对本轮目标，说明“怎样算达成”；完成定义（DoD）针对每个条目，说明“做到什么程度才算完成”，通常包括代码评审通过、自动化测试通过、文档更新、可演示部署等团队约定的条目。两者都在规划会前由产品负责人和技术负责人对齐，会上只做确认和补充，避免在选范围的同时争论“什么算做完”，拖长会议并让承诺失真。
规划输入清单可以按以下五项准备：已排序需求（含验收要点）、上轮遗留条目及重新评估结论、本轮已知依赖与外部时间点、团队人员可用情况、上轮实际速率。五项齐备后，再进入容量测算。
容量怎么算：把可用人力换成可承诺的工作量
容量测算回答一个数量问题：这一轮团队实际能承接多少工作。做法是用“可用人力”和“历史速率”两个口径交叉校验，取偏保守的结果作为上限，再据此挑选范围。
容量测算字段
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 成员 | 参与本轮的角色与姓名 | 识别关键角色是否缺位 |
| 可用天数 | 迭代总工作日减去请假、培训、值班等 | 折算真实投入时间 |
| 支持与占用 | 线上支持、会议、跨团队协作等固定占用比例 | 避免把名义工时当可用工时 |
| 历史速率 | 近三到五轮实际完成的工作量（按团队统一的估算单位） | 提供经验基准 |
| 本轮调整项 | 新成员加入、技术预研、环境迁移等一次性因素 | 修正基准值 |
计算步骤与取偏保守值
- 按成员汇总可用天数，扣除请假与固定支持占用，得到本轮总可用人天。
- 取近三到五轮实际完成工作量的中位数或偏低值作为历史速率，剔除明显异常的一轮。
- 用可用人天与历史速率分别推算可承接量，两者不一致时取较小值；差异过大时先查原因（估算单位是否漂移、人员结构是否变化），再定上限。
- 从上限中预留一小部分给计划外支持与缺陷处理，通常按团队经验取一成左右，剩余部分才是可承诺的工作量。
容量结果写成一句话结论，例如“本轮可承诺约 X 个单位，其中预留 Y 给计划外事项”，作为选范围的硬约束。范围选择时按优先级从高到低装入，装到上限即停，剩余条目留在需求池等待下一轮，不因“看起来都快做完了”而超装。
从需求到Sprint Backlog：拆分、排序与依赖处理
选定范围后，把条目拆到“单个条目能在迭代内完成并验证”的粒度，再排出执行顺序。拆分和排序同时进行：先放必须完成项，再放可延后项，依赖项按前置关系调整位置。
排序规则
按价值与风险两个维度排序：直接支撑迭代目标的条目排在最前；技术风险高、验证周期长的条目尽早开始，给失败留出调整时间；依赖外部交付的条目确认前置时间点后再定位置。排序结果要让每个成员一眼看出“先做什么、为什么先做”。
拆分粒度标准
一个合格条目满足三条：能在本轮内完成；完成后可被演示或验证；负责人明确且不需要中途换人。过大的条目继续拆，过小的条目可合并，避免 Backlog 变成几十条无法跟踪的碎片。每条至少包含标题、验收要点、估算、负责人、依赖标注五项信息。
依赖与外部等待项的处理
跨角色依赖（如前端等待接口联调、测试等待环境就绪）在规划时逐条标注前置方和期望时间，形成依赖与风险清单。能在会前解决的依赖当场确认；无法确认的，明确“若某日前未就绪则调整范围”的触发条件，写进范围调整约定，避免迭代中途才发现被阻塞。
这些产物需要在协作工具中保持同一份事实来源：迭代目标、Backlog 条目、估算与负责人、依赖状态。在 ONES 中，可以把迭代目标写在迭代说明里，把拆分后的条目作为工作项挂到该迭代下，用状态和负责人字段跟踪进展，依赖与风险以标注或关联项记录，规划会结论与范围调整约定随迭代文档留存，供迭代中随时对照。
规划会怎么开：议程、角色分工与承诺方式
规划会的作用是把会前准备的结果对齐成团队承诺，而不是重新讨论需求。会议时长按迭代长度控制，两週迭代通常安排两到三小时，分两段：上半段确认目标与范围，下半段拆分条目与确认依赖。
议程与时间分配
| 环节 | 内容 | 参考时长 |
|---|---|---|
| 会前准备 | 需求排序、验收要点、容量表、遗留条目评估结论提前发出 | 会前完成 |
| 目标与验收口径 | 产品负责人讲解目标，团队确认可观察结果 | 约 20 分钟 |
| 容量与范围 | 核对容量结论，按优先级装入条目至上限 | 约 30 分钟 |
| 拆分与依赖 | 逐条确认粒度、负责人、依赖与风险 | 约 60 分钟 |
| 承诺与未决项 | 团队确认范围与风险，记录未决项及负责人 | 约 20 分钟 |
角色分工
- 产品负责人：说明目标与优先级依据，回答验收口径问题，对范围取舍做决定。
- 技术负责人：评估技术可行性与拆分合理性，识别技术风险与依赖。
- 团队成员：认领条目、给出估算、指出执行中的障碍，对“能否做完”表态。
- Scrum Master 或主持人：控制议程与时间，记录未决项和范围调整约定，确保承诺由团队共同确认。
承诺怎么形成
承诺的形成方式是团队逐条确认“这条我们能在本轮完成并验证”，而不是主持人分配、成员默认接受。对存疑条目当场标记：要么缩小范围，要么移出本轮，要么写明触发调整的条件。会议结束前留下三样记录：本轮范围清单、依赖与风险清单、未决项及负责人。未决项要有明确的解决时间点，不能悬空进入迭代。
迭代中范围怎么调：变更规则与未完成工作的处理
迭代开始后范围应保持稳定，但外部约束变化、线上问题、依赖延迟都可能要求调整。规则的作用是让调整有据可依，而不是每次临时商量。
范围变更的准入条件
新增工作进入本轮需同时满足：直接影响本轮目标或线上稳定性；有明确的需求方和验收口径；团队确认可以通过替换等量工作来承接。满足条件的变更由产品负责人提出、技术负责人评估影响、团队确认替换方案后执行，主持人在迭代记录中登记变更原因与被替换条目。不满足条件的请求进入需求池，按正常优先级排入后续迭代。
新增与替换的处理方式
优先采用“换入换出”：新增一项，移出等量的一项，保持总工作量不超容量。无法替换时，明确本轮目标是否受影响，受影响则同步调整目标表述，避免迭代结束时用“目标没变但没做完”解释。
未完成工作的处理
迭代结束时未完成的条目不做默认结转。逐条重新评估：价值是否仍然成立、是否需要重新拆分、优先级是否变化。评估后由产品负责人决定放回需求池、拆小后进入下一轮，或关闭。默认结转会让速率失真，也会让下一轮容量测算失去基准。
一个完整示例：两週迭代的规划过程
以下为演示情景，数字用于说明方法，不代表任何真实团队数据。
背景与目标：一个六人研发小组，两週迭代，共 10 个工作日。本轮目标定为“让新用户在不看帮助文档的情况下完成首次下单”，验收结果为可用性测试 5 人中至少 4 人独立完成，下单主流程在预发环境通过回归。
容量测算：六人中一人请假 2 天、一人有 3 天线上支持，合计可用约 52 人天；近三轮实际完成工作量中位数为 46 个单位，按偏保守取 44；预留约一成给计划外事项，可承诺约 40 个单位。
范围选择：按优先级装入“下单流程简化”“错误提示优化”“支付回调稳定性修复”等条目，累计 38 个单位，剩余 2 个单位留给小缺陷。两个依赖项标注前置方：支付渠道配置由外部团队在迭代第 3 个工作日提供，测试环境由运维在第 2 个工作日就绪。
规划会结论：团队确认 38 个单位范围与两项依赖时间点，记录一个未决项（优惠券规则是否纳入本轮，由产品负责人在第 2 个工作日答复）。
迭代中的一次调整：第 4 个工作日，支付渠道配置延迟到第 6 个工作日。团队按约定触发调整：将“支付回调稳定性修复”移出本轮，换入等量的“错误提示优化”补充条目，目标表述不变，变更原因与被替换条目登记在迭代记录中。迭代结束时，除移出条目外全部完成并演示，未完成条目经重新评估后拆小进入下一轮。
规划完成后怎么检查：完成标志与复盘改进
规划是否做到位，可以在会后就检查，也可以在迭代评审与回顾中用数据检验。
规划完成检查清单
| 检查项 | 通过标准 |
|---|---|
| 迭代目标 | 一句话目标加可观察的验收结果，数量不超过两个 |
| 容量测算 | 有可用人力与历史速率两个口径，取偏保守值并预留计划外余量 |
| Sprint Backlog | 每条含验收要点、估算、负责人、依赖标注，粒度可在本轮完成并验证 |
| 依赖与风险 | 逐条标注前置方与期望时间，无法确认的有触发调整条件 |
| 范围调整规则 | 变更准入条件、审批角色、替换方式、未完成处理方式均已写明 |
| 会议记录 | 范围清单、风险清单、未决项及负责人齐备 |
用评审与回顾检验规划准确度
迭代评审时对照目标验收结果，判断目标是否达成、达成的证据是否可演示；回顾时看三个指标：承诺范围与实际完成的比例、范围变更次数及原因分布、依赖延迟导致的阻塞时长。比例长期偏高说明容量测算过于保守或拆分过细，偏低说明估算偏乐观或计划外占用被低估；变更集中在某类原因时，下一轮规划应把对应约束提前确认。
下一轮规划要修正的输入
把本轮实际速率、未完成条目的重新评估结论、依赖延迟记录、变更原因汇总带入下一轮，替换掉过时的估算基准。规划质量的改进来自这些输入逐轮校准，而不是每次重新拍一个数字。
常见问题
迭代目标可以定几个？多个目标并行时怎么处理？
迭代目标控制在一个，最多两个。目标过多意味着优先级没有真正排出来，团队在范围取舍时缺少依据。如果确实存在多个方向，建议按价值与紧迫度选一个作为本轮目标，其余方向拆成后续迭代的目标，或作为不占用本轮承诺容量的探索性工作单独标注。
目标数量确定后，验收结果同步收敛到一到三条可观察的结果，避免目标一句话、验收结果列一长串。
团队没有历史速率数据，第一次迭代规划怎么定容量？
缺少历史速率时，先用可用人天做保守估算，并在本轮记录每条工作的实际投入与完成情况，作为后续速率的起点。具体做法：按成员可用天数扣除请假与固定支持占用，得到总可用人天；对条目做统一单位的估算；范围选择时在上限基础上再留出更大余量，把第一轮定位为校准轮。
前两到三轮结束后，用实际完成量替代初始估算作为基准。期间不要因为某一轮完成得多就大幅上调承诺，估算单位的稳定性比单轮数字更重要。
迭代中途插入紧急需求，一定要替换掉原有工作吗？
优先采用换入换出，保持总工作量不超容量。判断是否受理时看三个条件：是否直接影响本轮目标或线上稳定性；是否有明确需求方和验收口径；团队能否通过替换等量工作承接。三条同时满足才进入本轮，由产品负责人提出、技术负责人评估影响、团队确认替换方案。
如果无法替换，需要明确本轮目标是否受影响；受影响就同步调整目标表述，并在迭代记录中登记变更原因与被替换条目。不满足条件的请求进入需求池，按正常优先级排入后续迭代。
迭代结束时没做完的条目，直接放到下一轮有什么问题？
默认结转会让速率数据失真：本轮承诺了却没有完成，下一轮又带着这些条目开始，容量测算的基准会逐轮偏离实际。更稳妥的做法是逐条重新评估：价值是否仍然成立、是否需要重新拆分、优先级是否变化，再由产品负责人决定放回需求池、拆小后进入下一轮或关闭。
重新评估也给了团队一次检查机会：如果某类条目反复未完成，往往说明拆分粒度过大或依赖没有提前确认，这些结论应带入下一轮规划。
规划会开完，怎么判断这次规划是否合格？
会后即可对照检查清单：迭代目标是否为一句话加可观察验收结果；容量是否有可用人力与历史速率两个口径并预留余量；Backlog 每条是否含验收要点、估算、负责人和依赖标注；依赖与风险是否逐条标注前置方与时间点；范围调整规则与会议记录是否齐备。
迭代评审与回顾中再用数据检验：承诺范围与实际完成的比例、范围变更次数及原因分布、依赖延迟导致的阻塞时长。比例长期偏高或偏低、变更集中在某类原因，都指向下一轮规划需要修正的具体输入。
