迭代规划要把已排序、已估算的需求，转成团队愿意承诺的迭代目标和一份可执行的工作清单。具体做法是：先确认周期与可用容量，再从需求池按优先级挑选候选条目，逐条明确验收标准与依赖，团队共同确认迭代目标并拆分任务，最后用完成检查确认范围、责任人和风险都已落实。规划产出的迭代目标、范围清单、任务与负责人、风险与依赖记录，会成为执行跟踪和复盘的依据。规划结果通常需要在协作平台中承载状态与交接，ONES 的迭代与工作项管理可以承接这部分内容。
要点总览（TL;DR）
- 迭代规划先定三项输入：迭代周期与起止时间、团队可用容量、一句话迭代目标；目标决定取舍，容量决定上限。
- 从需求池筛选候选条目时，先确认已排序、已估算、验收标准可写，再按优先级累计到容量上限，并检查依赖关系。
- 上一轮未完成的工作逐条重新评估后再决定是否纳入本轮，不默认自动结转，避免范围无声累积。
- 规划会按目标确认、范围评审、任务拆分、风险确认、结论记录的顺序推进，产品负责人、团队成员、协调角色各有明确产出。
- 规划结束前用检查清单确认目标、范围、任务、责任人、依赖五项齐全，再进入执行；规划产出可在 ONES 的迭代与工作项中承载状态与交接。
迭代规划先定什么：周期、容量与目标
规划会开始前，有三项输入必须先确定：这一轮迭代从哪天到哪天、团队实际能投入多少工作量、这次迭代要达成什么结果。三项没有定下来就进入排任务，讨论很容易变成逐条争论，最后产出的清单也缺少取舍依据。
周期与起止时间
迭代周期由团队根据交付节奏和反馈频率约定，常见为一周、两周或四周。确定周期时同时写明起止日期、规划会时间、评审与回顾时间，并避开团队已知的集中休假或关键节点。周期一旦确定，本轮内保持不变；需要调整时，在下一轮规划前统一讨论。
可用容量的估算口径
容量指团队在本轮真正可用于迭代目标的工作量，估算时按以下顺序计算：
- 以参与成员的实际可用天数为基础，扣除法定假期、年假、培训与值班；
- 扣除支持性工作，例如线上问题处理、例行维护、评审与会议占用；
- 按团队习惯折算为故事点、人天或工时，同一团队保持口径一致；
- 预留一定缓冲，用于估算偏差和临时插入事项，比例由团队根据历史波动约定。
容量是上限，不是必须填满的指标。把容量当作目标去凑满，会让迭代一开始就处于超载状态。
迭代目标的写法
迭代目标用一句话说明本轮要达成的业务或用户结果，例如“让新用户完成首次配置的步骤从五步减到三步”。好的目标具备三个特征：指向具体用户或业务场景，结果可以被验证，团队通过本轮工作能够独立达成。目标决定取舍：当候选条目超出容量时，优先保留支撑目标的部分，其余移出。
规划输入说明可以按以下结构记录：迭代周期与起止时间、参与成员与可用天数、支持性工作扣除项、容量估算结果与缓冲比例、候选迭代目标一句话。这份说明是后续范围筛选和会议讨论的共同起点。
从需求池到迭代范围：筛选与排序的操作步骤
范围筛选的任务，是从需求池中挑出本轮要做的条目，并给出取舍理由。筛选的前提是条目已经具备准入条件，否则讨论会退回到需求澄清阶段。
候选条目的准入条件
- 已在需求池中完成排序，优先级有明确依据；
- 已完成估算，团队对工作量有共同判断；
- 验收标准可以写出来，能够判断“做完”是什么状态；
- 已知的外部依赖有初步说明。
不满足准入条件的条目留在需求池继续梳理，不进入本轮候选范围。需求池的排序与优先级方法属于需求池管理的范畴，本文不展开。
按优先级与依赖筛选
操作顺序建议为：先按优先级从高到低取候选条目，累计工作量接近容量上限时停止；再检查条目之间的依赖关系，把必须先完成的前置条目一并纳入，或把依赖未就绪的条目移出；最后对照迭代目标复核，确认入选条目整体支撑目标，而不是各自独立的高优先级集合。范围确认后形成迭代范围清单，每条注明优先级、估算值、验收标准要点和取舍理由。
未完成工作的处理
上一轮未完成的条目，不默认自动结转到本轮。处理方式是逐条重新评估：未完成的原因是什么，剩余工作量还有多少，优先级是否因时间推移发生变化，验收标准是否需要调整。重新评估后仍符合本轮目标的，作为新条目参与本轮筛选；不再符合的退回需求池。这样处理可以避免范围在无声中累积，也能让团队看清未完成的真实原因。
范围冻结与变更约定
范围确认后即冻结，作为执行跟踪的基准。变更需要约定入口：谁可以提出、由谁评估影响、什么情况下接受替换。常见约定是“等量替换”——插入新条目时移出等量工作量的条目，保持总量不超容量；影响迭代目标的变更需要产品负责人和团队共同确认。变更记录保留在迭代范围内，供复盘时查看。
任务拆分与责任人落实
范围条目确定后，需要拆成团队可以直接执行的任务，并明确每条任务的负责人和完成标志。拆分的目的，是让执行阶段每个人知道自己做什么、做到什么程度算完成。
拆分粒度
单条任务以数天内可完成为宜，便于日常跟踪和及时暴露问题。拆分过粗，任务长时间停留在进行中，风险发现得晚；拆分过细，管理成本上升。设计、研发、测试等角色可以按各自负责的部分拆分同一需求，形成子任务，便于后续处理和跟踪。
任务要素的写法
每条任务写明四项内容：输入（依据的需求、设计稿或接口文档）、动作（具体做什么）、输出（交付物形态）、完成标志（如何验证完成）。例如“完成登录接口联调：输入为接口文档与测试账号，动作为联调并修复差异，输出为联调记录，完成标志为主流程用例通过”。
负责人认领与交接点
负责人由团队成员认领，认领时确认工作量与自身容量匹配。跨角色协作的任务，需要标出交接点：谁在什么状态下移交给谁，交接时提供什么材料。例如设计任务完成并评审通过后移交研发，研发自测通过后移交测试。交接点写清楚，执行阶段的等待和返工就会减少。
依赖与外部条件登记
依赖分为团队内部依赖和外部依赖。内部依赖记录前置任务与后置任务的关系；外部依赖记录需要其他团队、供应商或环境提供的条件，以及预计就绪时间。每条依赖注明责任人和跟进方式，规划会上逐条确认，无法确认就绪时间的依赖，对应条目考虑移出本轮范围。
规划会议怎么开：议程与角色分工
规划会议的作用，是让团队对目标、范围和任务形成共同承诺，并把风险摆到桌面上。会议效率取决于会前材料是否齐备，以及各角色是否清楚自己的职责边界。
会前准备
会前应完成：迭代范围清单与取舍理由、容量估算结果、候选迭代目标、待确认的依赖清单。参与人包括产品负责人、全体团队成员，以及承担协调职责的 Scrum Master 或对应角色。时长按范围条目数量约定，通常控制在两小时以内，条目较多时可分两次进行。
会议议程顺序
- 目标确认：产品负责人说明本轮迭代目标及背景，团队确认目标可达成；
- 范围评审：逐条过范围清单，确认验收标准与优先级，处理争议条目；
- 任务拆分：团队按角色拆分任务，认领负责人，写明完成标志；
- 风险确认：逐条确认依赖与外部条件，记录风险及应对方式；
- 结论记录：汇总目标、范围、任务、负责人、依赖，明确变更约定。
角色职责边界
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 产品负责人 | 提供已排序的需求池，说明迭代目标与优先级依据，评审范围与验收标准，决定范围变更 | 迭代目标、范围清单、验收标准 |
| 团队成员 | 参与范围评审，拆分任务并认领，给出工作量判断，提出依赖与风险 | 任务清单、负责人、完成标志 |
| Scrum Master 或协调角色 | 组织会议、准备材料、控制议程节奏，记录结论与待办，跟踪依赖与风险的落实 | 会议记录、依赖与风险清单 |
结论记录与同步
会议结论记录应包含：迭代目标、范围条目及取舍理由、任务与负责人、依赖与风险、变更约定。记录在会后当天同步给参与人及相关干系人，作为执行阶段的唯一基准。会议中未达成一致的条目单独列出，注明责任人和确认时间，不留在口头状态。
一个迭代规划的填写示例
以下为演示情景，用于说明规划产出的完整形态，不代表真实客户案例。
示例背景与容量假设
某产品团队采用两周迭代，本轮共 8 名成员参与，扣除假期、培训与支持性工作后，可用容量折算为 60 点，预留 10% 缓冲，可承诺范围为 54 点。候选迭代目标为“让新用户完成首次配置的步骤从五步减到三步”。
迭代目标与范围条目
| 范围条目 | 优先级 | 估算 | 验收标准要点 |
|---|---|---|---|
| 配置流程合并为三步 | 高 | 21 | 新用户按引导可独立完成，步骤数与目标一致 |
| 配置页错误提示优化 | 高 | 8 | 常见错误均有明确提示与下一步指引 |
| 配置完成后的引导页 | 中 | 13 | 完成后进入引导页，展示下一步操作入口 |
| 配置数据埋点补充 | 中 | 8 | 关键步骤均有埋点，数据可查询 |
合计 50 点，在 54 点承诺范围内。原候选中的“配置模板市场”估算 20 点，因超出容量且不直接支撑本轮目标，移出至需求池。
任务拆分与负责人示例
- 配置流程交互稿：输入为需求与验收标准，输出为交互稿，完成标志为评审通过，负责人为设计角色；
- 配置流程前端改造：输入为交互稿，输出为可运行页面，完成标志为自测通过并移交测试，负责人为前端角色；
- 配置接口调整：输入为接口文档，输出为接口与联调记录，完成标志为主流程用例通过，负责人为后端角色；
- 错误提示用例编写与验证：输入为验收标准，输出为测试用例与执行记录，完成标志为用例全部执行，负责人为测试角色。
风险与依赖记录示例
- 依赖：引导页文案需运营团队提供，预计第 4 个工作日就绪，责任人为产品负责人，未就绪时引导页任务顺延并评估是否移出；
- 风险：埋点方案依赖数据平台确认字段口径，若第 3 个工作日未确认，埋点任务拆分为最小可用版本；
- 变更约定：插入新条目时等量移出，影响迭代目标的变更由产品负责人与团队共同确认。
规划完成检查：逐项确认再开始执行
规划结束前，用一份检查清单逐项确认，全部通过再进入执行。检查面向“能否开始执行”，而不是重新讨论方案。
| 检查项 | 通过标准 |
|---|---|
| 迭代目标 | 一句话写明业务或用户结果，团队确认可达成 |
| 范围清单 | 每条有优先级、估算和验收标准，取舍理由已记录 |
| 任务与负责人 | 每条任务有负责人、输入、输出和完成标志，无未认领任务 |
| 依赖与风险 | 每条依赖有责任人和预计就绪时间，风险有应对方式 |
| 容量匹配 | 范围总量不超过承诺容量，超载项已移出并记录 |
| 验收标准可验证 | 每条标准能通过演示、测试或数据判断是否达成 |
| 变更与未完成约定 | 变更入口、替换规则、未完成条目的重新评估方式已明确 |
检查中发现缺项的，当场补齐或把对应条目移出范围。五项核心内容——目标、范围、任务、责任人、依赖——任何一项缺失，规划都不算完成。
把规划落到协作工具中：状态与交接的承载
规划产出如果只停留在会议记录里，执行阶段的状态和交接就缺少统一依据。把目标、范围条目和任务放进协作工具，可以让负责人、状态和变更记录在同一处被跟踪。
在 ONES 中，产品负责人可根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审需求；对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务将需求拆分，便于后续处理和跟踪。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，任务工时统计可用于估算任务持续时间，看板与燃尽图用于实时掌控进度。迭代执行中，团队成员围绕迭代要完成的需求完成自己拆解的任务，并通过敏捷看板管理任务状态。
对应到规划产出，工具中的承载方式可以这样安排：迭代目标记录在迭代说明中；范围条目对应规划至该迭代的需求，验收标准写在需求描述里；任务对应需求下的子任务，负责人和完成标志写在任务字段中；依赖与风险记录在迭代的备注或关联条目中，注明责任人和跟进状态。规划结论与变更记录随迭代留存，复盘时可直接查看当时的范围与调整过程。
上一轮未完成的条目，在下一轮规划时从原迭代中取出，按本文的处理原则重新评估后再决定是否纳入新迭代。工具侧的具体迁移操作方式，以团队实际使用的功能为准；评估动作本身应在规划会上完成，并留下结论记录。
常见问题
迭代周期应该定多长，定下来后还能改吗？
周期由团队根据交付节奏和反馈频率约定，一周、两周、四周都是常见选择。确定时同时写明起止日期、规划会时间、评审与回顾时间，并避开已知的集中休假或关键节点。周期一旦确定，本轮内保持不变；需要调整时，放到下一轮规划前统一讨论，避免执行中途反复变更影响范围基准。
容量估算要不要留缓冲，留多少合适？
建议预留缓冲，用于估算偏差和临时插入事项。比例没有统一标准，可由团队根据历史波动约定，例如按可用工作量的 10% 左右预留。容量是上限而非必须填满的指标，把容量当目标去凑满，迭代一开始就会处于超载状态。缓冲比例确定后，在规划输入说明中记录，便于后续复盘时对照实际偏差调整。
上一迭代未完成的工作，可以直接带到下一轮吗？
不建议默认结转。处理方式是逐条重新评估：未完成的原因是什么，剩余工作量还有多少，优先级是否因时间推移发生变化，验收标准是否需要调整。重新评估后仍符合本轮目标的，作为新条目参与本轮筛选；不再符合的退回需求池。这样能避免范围在无声中累积，也让团队看清未完成的真实原因。
规划会上产品负责人和协调角色的职责怎么区分？
产品负责人负责提供已排序的需求池，说明迭代目标与优先级依据，评审范围与验收标准，并决定范围变更；产出是迭代目标、范围清单和验收标准。Scrum Master 或协调角色负责组织会议、准备材料、控制议程节奏，记录结论与待办，跟踪依赖与风险的落实；产出是会议记录、依赖与风险清单。团队成员参与范围评审、拆分任务并认领，给出工作量判断。三者职责写清楚，会上就不容易出现无人拍板或无人记录的情况。
规划结论记录后，执行中插入紧急需求怎么处理？
按规划时约定的变更入口处理。常见做法是等量替换：插入新条目时移出等量工作量的条目，保持总量不超容量；影响迭代目标的变更，由产品负责人和团队共同确认。变更记录保留在迭代范围内，复盘时可查看当时的范围与调整过程。约定要在规划会上明确，而不是等紧急需求出现后再临时商量。
