迭代规划要同时管住六类约束：需求范围与优先级、团队可用容量、依赖与外部交付、质量与技术底线、时间盒与会议节奏、风险与缓冲。规划时先锁定迭代目标与容量上限，再按优先级裁剪范围，把依赖和风险显式写入计划，最后用完成定义和缓冲规则约束执行。本文给出约束分类表、六步操作流程、角色分工和完成检查清单，帮助团队在规划会上逐项核对，形成一份可执行的Sprint Backlog。
要点总览（TL;DR）
- 迭代规划需要同时管住六类约束：需求范围与优先级、团队可用容量、依赖与外部交付、质量与技术底线、时间盒与会议节奏、风险与缓冲。
- 取舍顺序通常是先锁定时间盒和容量上限，再在容量内按优先级裁剪范围，依赖与质量底线决定需求能否进入迭代，风险与缓冲用于校准估算偏差。
- 规划可按六步推进：确认迭代目标与验收口径、核算容量、裁剪范围、识别依赖、设定质量底线与缓冲、形成Sprint Backlog并评审确认。
- 产品负责人、开发团队、技术负责人和规划组织者分别对范围、容量、技术质量与会议节奏负责，四类交付物构成一次完整规划的记录。
- 规划完成前用检查清单逐项核对，未完成工作需重新评估而非默认顺延，出现范围变更或依赖延迟时回到对应约束重新评估。
迭代规划先锁定哪些约束
迭代规划的核心任务，是在有限的时间盒内确定“这次能交付什么、凭什么能交付”。约束识别是这项工作的起点：遗漏任何一类约束，都会在迭代中后期以返工、延期或质量下降的形式暴露出来。规划会上可以按六类约束逐项过一遍，每类约束对应一个判断问题和一组规划动作。
| 约束类别 | 判断问题 | 规划动作 |
|---|---|---|
| 需求范围与优先级 | 本次迭代必须交付哪些需求？哪些可以推迟？优先级排序依据是什么？ | 从产品待办列表中按优先级选取候选需求，明确迭代目标，对候选需求做“必须/应该/可以”分层 |
| 团队可用容量 | 本迭代团队实际可投入多少人天？请假、支持、会议占用多少？ | 按成员核算可用工时，扣除休假与固定占用，得出容量上限并留出缓冲 |
| 依赖与外部交付 | 哪些工作依赖其他团队、外部供应商或上游系统？对方何时交付？ | 列出依赖清单，标注责任人和交付时间点，评估依赖未到位时的替代方案 |
| 质量与技术底线 | 完成定义包含哪些测试、评审和文档要求？技术债是否需要在本次迭代处理？ | 确认完成定义，预留测试与评审工作量，把必要的技术改进纳入范围 |
| 时间盒与会议节奏 | 迭代周期多长？规划、评审、回顾等会议占用多少时间？ | 固定迭代起止日期和会议安排，把会议时间计入容量核算 |
| 风险与缓冲 | 哪些不确定因素可能影响交付？缓冲留多少？ | 登记风险项，设定缓冲比例和触发条件，明确未完成工作的处理规则 |
六类约束之间存在取舍顺序。通常先锁定时间盒和容量上限，这两项在迭代内基本不可变；再在容量内按优先级裁剪范围；依赖和质量底线作为范围的附加条件，决定某些需求能否进入本次迭代；风险与缓冲最后校准，用于吸收估算偏差。当范围与容量冲突时，优先削减范围，保持时间盒和质量底线不变，这是迭代规划区别于长期项目计划的关键取舍。
按约束做迭代规划的操作步骤
把约束分类落到规划会上，可以按六个步骤推进。每一步都有明确的输入、动作、输出和完成标志，规划组织者可以据此控制会议节奏，避免讨论发散。
步骤一：确认迭代目标与验收口径
输入是产品待办列表和上一迭代的回顾结论。动作是由产品负责人提出本次迭代目标，说明目标对应的业务价值，并与团队逐条确认候选需求的验收标准。输出是一份迭代目标说明和带验收标准的候选需求清单。完成标志是团队对“本次迭代要解决什么问题”形成一致理解，每条候选需求都有可检验的验收条件。
步骤二：核算团队可用容量
输入是团队成员名单、迭代日历和已知的请假与外部支持安排。动作是逐人核算可用工时，扣除休假、培训、会议和固定的运维支持时间，汇总为团队容量上限。输出是一张容量表，按角色或成员列出可用工时和占用说明。完成标志是容量表经过团队确认，并明确预留的缓冲比例。工时统计和任务持续时间估算可以借助工具完成，ONES Project 提供任务工时统计，用于估算任务持续时间，团队可据此校准容量判断。
步骤三：按优先级裁剪候选范围
输入是候选需求清单和容量上限。动作是按优先级从高到低把需求放入迭代，累计工作量接近容量上限时停止，剩余需求退回产品待办列表。输出是本次迭代的需求范围。完成标志是范围内需求的总估算工作量不超过容量上限扣除缓冲后的可用量，且每条被移出的需求都有明确的推迟原因。在ONES中，产品负责人可根据需求优先级，将产品待办列表中的需求规划至对应迭代，在迭代计划会议上与团队共同进行需求评审。
步骤四：识别依赖与外部交付约束
输入是范围内需求和团队已知的外部协作关系。动作是逐条检查需求是否依赖其他团队、外部供应商或上游系统，记录依赖内容、对方责任人和承诺交付时间。输出是一份依赖清单。完成标志是每条依赖都有责任人和时间点，对无法确认交付时间的依赖，团队已准备降级方案或将其移出本次范围。
步骤五：设定质量底线与缓冲
输入是团队的完成定义和历史缺陷数据。动作是确认本次迭代的完成定义，包括测试覆盖、代码评审和文档要求，把测试与评审工作量计入容量；同时设定缓冲比例和风险触发条件。输出是完成定义说明和缓冲规则。完成标志是团队对“什么算完成”没有歧义，缓冲比例和风险应对方式已写入计划。
步骤六：形成Sprint Backlog并评审确认
输入是范围、容量表、依赖清单和完成定义。动作是把需求拆解为可执行任务，分配负责人，形成Sprint Backlog，并在规划评审中逐项核对约束。输出是经团队确认的Sprint Backlog。完成标志是每条任务都有负责人和估算，依赖与风险已登记，团队对迭代目标做出承诺。需求与验收标准达成一致后，设计、研发、测试人员可利用子任务将需求拆分，便于后续处理和跟踪。
各角色在约束确认中的分工与交付物
约束确认需要多个角色共同参与，分工不清会导致某些约束无人负责。下表按角色列出主要责任、需要确认的约束和对应交付物，团队可根据实际规模合并角色，但每类约束都应有明确的责任人。
| 角色 | 负责确认的约束 | 交付物 |
|---|---|---|
| 产品负责人 | 需求范围与优先级、验收口径 | 迭代目标说明、带验收标准的候选需求清单、优先级排序结果 |
| 开发团队 | 容量评估、任务拆解、完成定义 | 容量表、任务拆解结果、完成定义说明 |
| 技术负责人 | 技术依赖、质量底线、技术债处理 | 技术依赖清单、质量要求说明、技术改进项 |
| Scrum Master或规划组织者 | 会议节奏、依赖跟踪、风险登记 | 迭代日历、依赖与风险清单、规划会议记录 |
四类交付物构成一次完整规划的记录：迭代目标说明回答“为什么做”，容量表回答“能做多少”，Sprint Backlog回答“具体做什么”，依赖与风险清单回答“可能卡在哪里”。这些交付物在迭代执行中持续被引用，规划组织者应在迭代开始前确认它们已归档并可供团队查阅。
一个迭代规划的约束核对示例
以下为演示情景，用于说明约束如何落到具体规划动作，不代表真实客户案例。
某团队采用两周迭代，共6名成员。迭代日历显示一名成员休假3天，另有两人各需投入半天处理线上支持，扣除规划、评审、回顾等会议时间后，团队容量约为52人天。产品负责人带来8条候选需求，估算总量约70人天，其中两条依赖外部支付团队提供接口，交付时间尚未确认。
按容量上限裁剪范围时，团队先保留优先级最高的5条需求，合计约46人天，剩余3条退回产品待办列表并注明推迟原因。两条依赖外部接口的需求中，一条被拆分为“接口联调”和“本地模拟实现”两个任务，联调部分标注依赖责任人和期望交付时间；另一条因依赖时间无法确认，整体移出本次迭代。团队按10%预留缓冲，约5人天，用于吸收估算偏差。风险清单登记了两项：外部接口延迟和一名成员休假期间的交接风险，各自写明触发条件和应对方式。
规划评审时，团队逐项核对：迭代目标是否清晰、容量表是否扣除会议与休假、范围内需求总量是否在容量上限内、每条依赖是否有责任人和时间点、完成定义是否覆盖测试与评审、缓冲比例是否确认。核对中发现一条需求的验收标准描述模糊，产品负责人当场补充后重新确认。评审结束后，Sprint Backlog定稿，依赖与风险清单同步给相关外部团队。
规划完成前的检查项
规划会结束前，规划组织者可以用下面的清单逐项判断，任何一项无法确认，都应回到对应步骤补充，而不是带着未决问题进入迭代。
- 迭代目标是否用一句话说清，团队是否理解目标对应的业务价值；
- 每条范围内需求是否有可检验的验收标准；
- 容量表是否扣除休假、会议和固定支持时间，是否留出缓冲；
- 范围内需求的总估算工作量是否与容量上限匹配，超出部分是否已移出；
- 每条外部依赖是否有责任人和时间点，无法确认的依赖是否有降级方案；
- 完成定义是否覆盖测试、评审和文档要求，团队是否确认；
- 风险清单是否登记主要不确定因素，是否写明触发条件和应对方式；
- 未完成工作的处理规则是否说明，是否明确需要重新评估而非默认顺延；
- Sprint Backlog中每条任务是否有负责人和估算；
- 依赖与风险清单是否已同步给相关外部团队。
清单全部通过，说明本次规划已覆盖六类约束，可以进入执行阶段。迭代过程中如出现范围变更或依赖延迟，应回到对应约束重新评估，并同步更新Sprint Backlog和风险清单，保持计划与实际一致。
常见问题
迭代规划时范围与容量冲突，应该先削减哪一项？
通常优先削减范围，保持时间盒和质量底线不变。时间盒和容量上限在迭代内基本不可变，范围是唯一可以按优先级灵活调整的变量。具体做法是按优先级从高到低把需求放入迭代，累计工作量接近容量上限扣除缓冲后的可用量时停止，剩余需求退回产品待办列表并注明推迟原因。
如果削减范围后仍无法满足目标，需要回到迭代目标本身重新讨论，确认是否把部分目标推迟到下一个迭代，而不是压缩测试与评审工作量。
外部依赖的交付时间无法确认时，这条需求还能进入本次迭代吗？
可以进入，但需要附加条件。团队应把依赖拆分为可独立推进的部分，例如把“接口联调”与“本地模拟实现”分开，联调部分标注依赖责任人和期望交付时间，并准备降级方案。如果依赖时间完全无法确认，且降级方案也无法保证交付，较稳妥的做法是整体移出本次迭代，避免迭代后期因外部延迟导致范围失控。
无论采用哪种处理，依赖内容、责任人和时间点都应写入依赖清单，并在规划评审时逐项核对。
容量核算时，会议和固定支持时间要不要计入？
需要计入。容量核算应逐人扣除休假、培训、规划与评审等会议时间，以及固定的线上支持或运维占用，汇总后的结果才是团队实际可投入的容量上限。在此基础上再预留一定比例的缓冲，用于吸收估算偏差和临时插入事项。
把会议与支持时间排除在容量之外，会让计划看起来饱满，实际执行时却频繁出现任务无法完成的情况。ONES Project 提供任务工时统计，可用于估算任务持续时间，帮助团队校准容量判断。
迭代规划完成后，执行中出现范围变更怎么处理？
范围变更应回到对应约束重新评估，而不是直接在Sprint Backlog中追加任务。先判断变更影响哪类约束：新增需求影响范围与容量，外部延迟影响依赖，质量问题影响完成定义。评估后同步更新Sprint Backlog、依赖清单和风险清单，保持计划与实际一致。
如果变更导致容量超限，需要按优先级移出等量的原有需求，或与产品负责人确认是否调整迭代目标。变更处理规则最好在规划阶段就说明，减少执行中的反复讨论。
未完成的工作可以直接结转到下一个迭代吗？
未完成工作需要重新评估，不宜默认自动结转。结转前应确认三件事：这项工作是否仍然符合下一个迭代的目标和优先级；剩余工作量是否被重新估算；未完成的原因是否会影响后续计划，例如依赖延迟或估算偏差。
重新评估后，符合条件的工作可以纳入下一个迭代的候选范围，与其他需求一起按优先级参与裁剪；不再符合目标的工作则退回产品待办列表。规划完成前的检查清单中应包含这一处理规则，避免结转成为默认动作。
