迭代规划要解决的是三件事的对齐：这个迭代要达成什么、团队能做多少、先做哪些。本文按“目标与候选需求—容量核算—规划会—执行跟进—未完成工作处置”的顺序给出可执行步骤，每一步说明输入、动作和输出，并附角色分工、两周迭代示例与完成检查清单。文中会自然提到ONES在承载迭代目标、任务拆分与进度跟进上的用法，工具选择可按团队现有流程判断。
要点总览（TL;DR）
- 迭代规划的产物是一份可执行的Sprint Backlog：先定可观察的迭代目标，再从需求池挑出通过就绪检查的候选需求，最后用容量核算结果约束承诺范围。
- 容量核算按人数、可用天数、请假与固定占用逐项计算，并用历史速率校验；缓冲比例依据过去插入事项的实际占比确定，不凭感觉设定。
- 规划会按目标对齐、需求澄清、任务拆分、估算、承诺确认五段推进，任务拆到一人两三天可独立完成，超容量时按目标相关性、依赖位置、价值顺序取舍。
- 执行期每日跟进剩余工作量、阻塞项与目标偏差；范围调整需有触发条件和决策人，新增需求按“进一出一”替换，保持总容量不变。
- 迭代结束时未完成工作先分为仍有效、需重估、应关闭三类，重新评估后再决定是否进入下个迭代候选，并记录估算偏差原因用于修正下轮容量。
迭代规划要产出什么：一份可执行的Sprint Backlog
迭代规划的最终产物是一份团队愿意承诺、并且能逐条执行的Sprint Backlog。它需要同时回答四个问题：本次迭代为什么做（迭代目标）、做哪些需求（候选需求范围）、能做多少（团队容量）、做到什么程度算完成（完成定义）。这四项构成规划的输入，缺一项，规划会就容易变成拍脑袋分任务。
规划会上的关键动作有四个：澄清需求、拆分任务、估算工作量、确认承诺。澄清是把模糊需求问清楚，拆分是把需求落到可独立推进的任务，估算是给任务一个团队认可的规模或工时，承诺是团队明确表示“这个范围我们在本迭代内可以完成”。四个动作有先后依赖，跳过澄清直接估算，往往会在执行中反复返工。
| 输入 | 规划会关键动作 | 产物 |
|---|---|---|
| 迭代目标：本迭代要达成的可观察结果 | 目标对齐，确认优先级顺序 | 写在Sprint Backlog顶部的迭代目标 |
| 候选需求：从需求池中挑出的待选条目 | 逐条澄清，确认验收标准 | 需求条目及其验收标准 |
| 团队容量：本迭代可用人力与历史速率 | 估算并与容量比对，做取舍 | 任务估算值与负责人 |
| 完成定义：什么样的工作算做完 | 确认承诺，形成可执行清单 | 带状态字段的Sprint Backlog |
Sprint Backlog应包含的字段建议固定下来：需求（含验收标准）、拆出的任务、任务负责人、估算值、当前状态。字段固定后，每日跟进和迭代结束复盘才有统一口径。在ONES中，产品负责人可以按优先级把需求规划到对应迭代，团队就需求与验收标准达成一致后，用子任务拆分需求并分配负责人，使这份Backlog在工具里直接成为执行依据。
第一步：确定迭代目标与候选需求范围
迭代目标要写成可观察的结果，而不是任务清单。“完成订单模块重构”是任务描述，“下单流程在高峰期响应时间降到2秒以内”才是可验证的目标。好的迭代目标通常包含对象、变化和判断标准，团队在迭代结束时能明确回答“达成了没有”。一个迭代设一个主目标即可，附带一两个次要目标，目标过多等于没有重点。
候选需求的筛选依据有四项：价值（对用户或业务的实际影响）、依赖（是否依赖其他团队或前置工作）、风险（技术不确定性高低）、就绪程度（需求描述与验收标准是否清楚）。价值高、依赖已解除、风险可控、描述清楚的需求优先进入候选；风险高的需求可以安排一个探索性条目，但要单独标注，避免把不确定性混进常规承诺。
需求就绪的判断标准可以固化为检查清单，规划会前由产品负责人逐条确认：
- 需求描述能让不了解背景的开发者读懂；
- 验收标准可测试，写明输入、预期结果和边界情况；
- 依赖项已确认可用时间，或已明确不在本迭代解决；
- 需求规模适合在一个迭代内完成，过大的已拆分；
- 优先级已排定，出现取舍时有明确顺序。
迭代目标模板可以这样填写：“本迭代结束时，【目标用户】能够【完成什么动作】，判断标准是【可观察的指标或验收条件】。”候选需求就绪检查清单则在规划会前一天完成，未通过检查的条目留在需求池，不进入本次候选。
第二步：核算团队容量与可用工时
容量核算的目的是给承诺设一个现实上限。核算要素包括：参与人数、本迭代内每人的可用天数、请假与会议等非开发时间占用、以及团队的历史速率。按工时口径计算时，用“人数×可用天数×每日有效工时”得出理论容量，再扣除评审、会议、支持等固定占用；按历史速率口径计算时，直接参考过去几个迭代实际完成的规模平均值。
两种口径适用场景不同。团队估算稳定、历史数据积累足够时，按历史速率更可靠，因为它自动包含了沟通损耗和意外中断；团队刚组建、估算单位尚未统一时，按工时核算更直观，但要明确“有效工时”不含会议和碎片时间。实践中可以两者并用：用历史速率定总量，用工时校验单个任务的估算是否离谱。
容量是否需要留缓冲，取决于团队工作的可预测性。存在线上支持、跨团队协作或需求波动较大的团队，通常需要预留一部分容量应对插入事项；工作稳定、流程成熟的团队可以少留。缓冲比例没有统一标准，判断依据是过去几个迭代插入事项实际占用的比例，用历史数据反推比凭感觉设定更可靠。
| 字段 | 计算方式 | 说明 |
|---|---|---|
| 参与人数 | 直接填写 | 本迭代实际投入的成员数 |
| 迭代可用天数 | 迭代工作日 − 公共假期 | 按团队日历计算 |
| 个人可用天数 | 迭代可用天数 − 请假天数 | 逐人核算后汇总 |
| 固定占用 | 会议、评审、支持等预估工时 | 从可用工时中扣除 |
| 理论容量 | Σ（个人可用天数 × 每日有效工时）− 固定占用 | 工时口径 |
| 历史速率 | 过去若干迭代实际完成量的平均值 | 速率口径，注明统计区间 |
| 缓冲后可用容量 | 理论容量或历史速率 ×（1 − 缓冲比例） | 缓冲比例依据历史插入事项占比 |
第三步：开好规划会，把候选需求拆成可执行任务
规划会的议程建议按五段推进：目标对齐（产品负责人讲清本迭代目标与优先级）、需求澄清（逐条确认验收标准与边界）、任务拆分（团队把需求拆成可独立推进的任务）、估算（对任务给出规模或工时）、承诺确认（比对容量，明确本次范围）。议程要控时，澄清阶段发现需求未就绪的，直接移出本次候选，不在会上临时补需求描述。
拆分粒度的判断标准是“一个任务能被一个人在两三天内完成，并且可以独立判断完成与否”。过粗的任务在执行中无法反映真实进度，过细的任务会让跟进成本超过收益。估算方式上，故事点适合估算相对规模和长期速率跟踪，工时适合需要与外部排期对齐的场景；同一团队应保持口径一致，避免混用导致速率失真。
承诺与预测要区分开：预测是“按当前信息估计能完成多少”，承诺是“团队确认这个范围在本迭代内交付”。承诺不意味着范围永远不变，而是变更要走显式决策。当候选需求总量超过容量时，取舍顺序建议为：先保迭代目标直接相关的需求，再保依赖关系上处于前置位置的需求，最后按价值排序取舍；被移出的需求记录移出原因，回到需求池等待下个迭代。
任务拆分示例：需求“支持按订单号查询物流轨迹”，可拆为“接口字段与返回结构确认”“查询接口开发”“异常状态处理”“前端查询页对接”“联调与验收用例执行”五个任务，每个任务标注负责人和估算，验收标准沿用需求条目中的可测试条件。在ONES中，团队就需求与验收标准达成一致后，设计、研发、测试人员用子任务完成这类拆分，后续处理和跟踪都落在同一需求下。
执行中的每日跟进与范围调整规则
迭代开始后，每日跟进看三样东西：剩余工作量与剩余天数的对比、阻塞项及其责任人、已完成任务与迭代目标的偏差。剩余工作量用任务估算的剩余值累计，比“完成了几个任务”更能反映真实进度。跟进记录建议包含日期、各任务剩余估算、新增阻塞项、阻塞责任人与预计解除时间、对目标的影响判断。
范围调整要有触发条件和决策人。触发条件可以是：关键依赖延期、出现影响目标的高优先级缺陷、插入事项占用超过预留缓冲。决策人通常是产品负责人，技术风险部分由团队负责人判断；调整结论要记录在迭代记录中，写明调整内容、原因和影响。没有触发条件的临时加需求，不应直接进入当前迭代。
新增需求进入当前迭代的条件建议为：与迭代目标直接相关、有明确验收标准、团队确认移除等量工作作为替换。替换规则是“进一出一”，即新增多少工作量，就从当前范围中移出相当的工作量，保持总容量不变。这样既保留了响应变化的空间，也避免范围无声膨胀。ONES的敏捷看板可以在每日站立会议中可视化呈现任务状态，帮助团队对齐进度与风险；燃尽图则用于观察剩余工作与理想线的偏离程度。
未完成工作怎么处理：重新评估而非默认结转
迭代结束时未完成的工作，先分类再处置：仍有效（价值未变、依赖未变）、需重估（范围或条件发生变化）、应关闭（价值消失或被其他方案替代）。分类依据是剩余价值、依赖变化和估算偏差原因，三者中任何一项发生实质变化，都应重新评估而不是原样带入下个迭代。
估算偏差原因要记录，常见类型包括需求理解偏差、拆分粒度过粗、依赖未按期解除、插入事项挤占。记录偏差原因的价值在于修正下个迭代的容量核算和拆分习惯，而不是追究个人。重新排入下个迭代的条件是：需求仍符合当前目标方向、验收标准仍然有效、剩余工作已重新估算、优先级在候选需求中仍靠前。满足条件的条目进入下个迭代候选，并在记录中注明“上迭代未完成、已重估”。
| 分类 | 判断依据 | 处置动作 | 记录要求 |
|---|---|---|---|
| 仍有效 | 价值与依赖未变，剩余工作明确 | 重新估算后进入下个迭代候选 | 注明来源迭代与重估结果 |
| 需重估 | 范围、条件或依赖发生变化 | 回到需求池，补充信息后重新排序 | 写明变化点与偏差原因 |
| 应关闭 | 价值消失或被替代方案覆盖 | 关闭并说明理由 | 保留关闭原因，便于回溯 |
角色分工与各环节交付物
迭代规划涉及三类角色，职责边界清楚，规划会才不会变成产品负责人单方面派活。产品负责人对“做什么、为什么做”负责，开发团队对“怎么做、做多少”负责，Scrum Master对“流程是否按约定运行”负责。
| 角色 | 关键动作 | 交付物 |
|---|---|---|
| 产品负责人 | 设定迭代目标，排定需求优先级，编写并确认验收标准，主持范围调整决策 | 迭代目标、候选需求清单、验收标准、范围调整记录 |
| Scrum Master | 组织规划会与每日跟进，保障议程与规则执行，跟踪阻塞项清除 | 规划会议程与纪要、跟进记录、阻塞项清单 |
| 开发团队 | 拆分任务，给出估算，确认承诺，执行中反馈剩余工作与风险 | 任务清单与估算、承诺范围、每日剩余工作更新 |
三类角色的交付物在时间上衔接：产品负责人的目标与候选需求是规划会输入，开发团队的任务与估算是会议输出，Scrum Master的纪要与跟进记录贯穿执行期。任何一环缺失，后续的范围调整和未完成工作处置都会缺少依据。
一个完整示例：两周迭代的规划过程
以下为演示情景，用于说明步骤衔接，不代表真实项目数据。某研发团队共6人，迭代周期两周，共10个工作日，其中1人请假2天，团队每周固定会议占用约半天。按工时口径，理论容量约为（6×10 − 2×1人日 − 会议占用）个有效人日；参考过去三个迭代的实际完成量，团队确定本次按历史速率安排，并预留一部分容量应对线上支持。
产品负责人设定的迭代目标是“新用户注册流程完成改版并可全量上线”，候选需求包括注册页改版、短信验证码接口替换、注册转化埋点、老用户迁移提示四项。规划会上，团队逐条澄清验收标准，将注册页改版拆为页面结构、表单校验、错误提示、联调验收四个任务，短信验证码接口替换拆为接口对接与异常重试两个任务。估算后总量略超缓冲后容量，团队按取舍顺序移出“老用户迁移提示”，记录移出原因后回到需求池。
执行到第八个工作日，短信服务商接口变更导致验证码任务阻塞，产品负责人判断该依赖影响迭代目标，决定将“注册转化埋点”移出本迭代，保证注册流程上线。迭代结束时，注册页改版与验证码替换完成，埋点任务未完成。收尾时团队将其归类为“仍有效”，重新估算后进入下个迭代候选，并记录偏差原因为依赖变更导致的排期挤占。整个过程在ONES中对应需求规划至迭代、子任务拆分、看板跟进与燃尽图观察，使目标、任务和调整记录保持在同一处。
完成检查：迭代规划做对了没有
规划是否合格，可以用三组检查项逐条核对。任何一项不通过，都应在进入执行前修正，而不是带到迭代中补救。
- 规划前：迭代目标是否写成可观察结果；候选需求是否全部通过就绪检查；容量是否按人数、可用天数、固定占用和历史速率核算；完成定义是否团队一致认可。
- 规划会输出：每条需求是否有可测试的验收标准；任务拆分粒度是否在可独立完成的范围内；估算口径是否统一；承诺范围是否在缓冲后容量之内；超容量取舍是否有记录。
- 执行与收尾：每日跟进是否更新剩余工作与阻塞项；范围调整是否有触发条件、决策人和记录；未完成工作是否完成分类与重估；偏差原因是否记录并用于下个迭代的容量修正。
阻断条件可以设为：迭代目标缺失或不可验证、候选需求未通过就绪检查、承诺范围明显超过容量且无取舍记录、未完成工作未经重估直接带入下个迭代。出现任一情况，先补齐再进入下一轮规划，避免问题在多个迭代中累积。
常见问题
迭代目标写成一个季度的大方向可以吗？
不建议。迭代目标要能在本迭代结束时明确判断达成与否，季度方向适合作为上层目标，迭代目标应落到具体对象和可观察结果上。一个迭代设一个主目标，附带一两个次要目标即可；目标过多时，团队在取舍时缺少明确依据，规划会容易变成按人分任务。
团队估算口径不统一，故事点和工时能混用吗？
同一团队在同一时期应保持一种口径。故事点适合跟踪相对规模和长期速率，工时适合与外部排期对齐；混用会让历史速率失去可比性，容量核算的参考值也随之失真。团队刚组建、估算单位尚未统一时，可以先按工时核算容量，同时用几个迭代积累速率数据，再决定是否切换口径。
迭代中途插入紧急需求，一定要替换掉原有工作吗？
插入需求是否替换，取决于它是否与迭代目标直接相关、是否有明确验收标准，以及团队是否确认移出等量工作。与目标无关的紧急事项，优先由产品负责人评估后放入下个迭代候选；确需进入当前迭代的，按“进一出一”移出相当工作量，保持总容量不变，并把调整内容、原因和影响记录在迭代记录中。
未完成工作重新评估后，优先级下降了怎么办？
重新评估的结论可以是继续排入下个迭代候选，也可以是回到需求池重新排序。判断依据是剩余价值、依赖变化和估算偏差原因：价值仍在、依赖未变、验收标准仍有效的条目，重估后进入候选；范围或条件发生实质变化的，回到需求池补充信息后再排序；价值消失或被替代方案覆盖的，直接关闭并保留关闭原因。
规划会开完发现承诺范围还是偏大，怎么补救？
在进入执行前修正，比带到迭代中补救更稳妥。可以按取舍顺序移出与迭代目标关联较弱的需求，记录移出原因后回到需求池；也可以把规模过大的需求拆出一个可独立交付的部分，剩余部分留到下个迭代。修正后重新核对承诺范围是否在缓冲后容量之内，并同步更新Sprint Backlog。
