迭代计划需要考虑五类约束：团队可用容量、需求范围与优先级、依赖与外部交付时点、质量与验收门槛、风险与缓冲。做法是先锁定扣除休假、支持与会议后的真实容量，再按优先级裁剪范围，把依赖和验收标准写进计划，最后预留缓冲并写明范围调整规则。计划的价值在于留出可调整的边界，而非一次排满。
要点总览（TL;DR）
- 迭代计划要同时约束五类条件：团队可用容量、需求范围与优先级、依赖与外部交付时点、质量与验收门槛、风险与缓冲。
- 操作顺序是先核算净容量，再确定迭代目标并按优先级裁剪范围，然后标注依赖、写入验收标准，最后预留缓冲并写明范围调整规则。
- 产品负责人负责迭代目标、优先级和验收标准，迭代负责人负责容量核算、依赖协调和会议组织，开发团队负责估算、拆解和风险识别。
- 计划定稿前逐项核对容量扣除、验收标准、依赖时点、缓冲与调整触发条件，未完成需求重新评估后再决定是否纳入下一迭代。
迭代计划先锁定哪些约束
迭代计划的约束来自五个方向，每一类都有明确的输入来源和确认责任人。计划会议前把这些条件摆到桌面上，比在会上临时争论更有效。
| 约束类型 | 输入来源 | 确认责任人 | 是否可调整 |
|---|---|---|---|
| 容量 | 人员日历、休假记录、支持值班安排、会议占用、历史投入数据 | 迭代负责人 | 迭代内基本固定，跨迭代可调整 |
| 范围 | 需求优先级排序、迭代目标、候选需求清单 | 产品负责人 | 可调整，是主要的裁剪对象 |
| 依赖 | 外部团队交付节点、第三方接口时间、上下游系统排期 | 迭代负责人协调，产品负责人确认 | 通常不可压缩，只能提前识别 |
| 质量 | 验收标准、完成定义、测试环境与测试资源 | 产品负责人与开发团队共同确认 | 标准本身不降低，实现方式可讨论 |
| 风险 | 历史波动数据、技术不确定性、人员变动 | 开发团队识别，迭代负责人汇总 | 通过缓冲吸收，不消除 |
这五类约束之间存在取舍关系。容量固定时，范围是唯一可以自由裁剪的变量；范围固定时，就需要调整时间或补充人力，或者接受质量门槛的重新协商。计划会议的核心工作，就是在容量、范围、时间三者之间找到一个团队能够承诺的组合。依赖和风险属于外部条件，计划能做的是提前标注、预留缓冲，而不是在迭代中途临时补救。
确认责任人这一列常被忽略。容量由迭代负责人核算，范围由产品负责人拍板，质量门槛需要产品和开发共同确认。如果某类约束没有明确的责任人，计划会上就会出现“大家都觉得没问题、执行时才发现缺口”的情况。
按步骤制定一份可执行的迭代计划
从容量核算到计划定稿，可以拆成六步。每一步都有输入、动作、输出和完成标志，按顺序推进，避免在范围还没裁剪时就开始拆任务。
第一步：核算可用容量
输入是团队人员名单、迭代周期内的休假与请假记录、支持值班安排、固定会议占用。动作是把每个人的可投入天数逐项扣除，得到团队总可用人力天数。输出是一张容量核算表，按人列出名义天数、扣除项和净可用天数。完成标志是团队对净容量数字达成一致，并明确容量中是否包含代码评审、缺陷修复等日常工作的比例。
第二步：确定迭代目标并排序候选需求
输入是产品待办列表和本迭代希望达成的业务目标。动作是由产品负责人提出一个清晰的迭代目标，把候选需求按优先级排序，并标注每项需求的规模估算。输出是一份带优先级的候选需求清单。完成标志是迭代目标能用一句话说清，候选需求的总规模明显大于容量，为后续裁剪留出空间。
第三步：按容量裁剪范围，形成Sprint Backlog
输入是净容量和排序后的候选需求。动作是从高优先级开始逐项纳入，累计规模接近容量上限时停止，剩余需求退回待办列表。输出是本迭代的Sprint Backlog。完成标志是Backlog总规模不超过容量，且每项需求都有明确的负责人。在ONES中，产品负责人可以按需求优先级把产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审，这一步的产出可以直接落在迭代的工作项列表里。
第四步：标注依赖与外部交付时点
输入是Backlog中涉及外部团队、第三方接口或上下游系统的需求。动作是逐条标注依赖对象、需要的交付内容和最晚到位时间，指定对接人。输出是依赖清单，附在计划旁边。完成标志是每条外部依赖都有交付时点和对接人，且时点早于本迭代中依赖它的任务开始时间。
第五步：写入验收标准与完成定义
输入是每项需求的业务描述和质量要求。动作是由产品负责人补充验收标准，团队确认完成定义，包括代码评审、测试通过、文档更新等共同门槛。输出是带验收标准的需求条目和一份团队完成定义。完成标志是每条需求都能被独立验证，测试人员可以据此编写测试用例。ONES的资料提到，测试工程师可根据迭代要完成的需求与验收标准编写测试用例并执行，验收标准写得越具体，这一步越顺畅。
第六步：预留缓冲并设定范围调整规则
输入是历史波动数据和本迭代的风险识别结果。动作是按团队历史完成率的波动幅度预留缓冲，可以体现为少纳入一定比例的需求，或为高风险事项单独留出时间；同时写明范围调整的触发条件，例如某项依赖延迟超过约定天数、出现阻塞性缺陷时，由谁决定移除哪条需求。输出是缓冲安排和一份简短的范围调整规则。完成标志是团队知道在什么情况下可以调整范围、由谁决策、调整后如何同步。
六步完成后，团队对当前迭代要完成的需求与验收标准已经达成一致，设计、研发、测试人员可以利用子任务把需求拆分，便于后续处理和跟踪。这一步拆分属于执行准备，计划本身在第六步已经定稿。
角色分工与各阶段交付物
迭代计划涉及三个角色，职责边界清楚，计划才不会在评审时反复返工。
| 角色 | 主要职责 | 交付物 | 决策权范围 |
|---|---|---|---|
| 产品负责人 | 提出迭代目标，排序需求优先级，编写验收标准 | 迭代目标说明、带优先级的候选需求清单、验收标准 | 决定范围取舍的优先顺序；范围调整时决定移除或替换哪条需求 |
| 迭代负责人（Scrum Master） | 核算容量，组织计划会议，协调外部依赖，跟踪风险 | 容量核算表、依赖清单、计划会议记录、范围调整规则 | 确认容量数字；在触发条件满足时发起范围调整讨论 |
| 开发团队 | 评估工作量，拆解任务，识别技术与资源风险 | 规模估算、子任务拆解、风险清单 | 对工作量估算和完成定义有最终发言权；对无法在容量内完成的范围提出异议 |
职责重叠最常见的地方是范围决策。产品负责人排优先级，但范围能否装进容量由开发团队的估算决定，两者需要共同确认，任何一方单独承诺都容易在迭代中途失守。迭代负责人的角色是让这个确认过程有据可依：容量表、依赖清单和调整规则都是讨论的依据。
计划评审时，三个角色各自确认自己的交付物是否齐全。范围调整发生时，产品负责人决定取舍，迭代负责人更新计划并通知相关方，开发团队重新评估受影响任务的工作量。决策权写清楚，调整就不需要每次重新开会争论。
一个迭代计划的约束填写示例
以下为演示情景，用于说明约束如何落到计划表，数据为示例设定。
背景：两周迭代，团队5人，其中1人休假3天，1人每周有1天支持值班，团队每周固定会议合计每人约2小时。按每人10个工作日计算，名义人力为50人天；扣除休假3人天、支持值班2人天、会议占用约2.5人天，净可用容量约42.5人天，再按历史数据留出约10%的波动缓冲，计划可承诺规模约38人天。
候选需求清单按优先级排列：需求A（支付流程改造，8人天，依赖第三方接口在迭代第5个工作日交付）、需求B（报表导出优化，6人天）、需求C（权限模型调整，10人天，依赖上游团队第8个工作日交付）、需求D（消息通知模板，5人天）、需求E（移动端适配，12人天）、需求F（日志检索，7人天）。
| 纳入顺序 | 需求 | 规模（人天） | 累计 | 依赖标注 | 处理决定 |
|---|---|---|---|---|---|
| 1 | 需求A 支付流程改造 | 8 | 8 | 第三方接口第5个工作日交付，对接人已指定 | 纳入，接口延迟超过2天则触发范围调整 |
| 2 | 需求C 权限模型调整 | 10 | 18 | 上游团队第8个工作日交付 | 纳入，但排在依赖到位后执行 |
| 3 | 需求B 报表导出优化 | 6 | 24 | 无 | 纳入 |
| 4 | 需求F 日志检索 | 7 | 31 | 无 | 纳入 |
| 5 | 需求D 消息通知模板 | 5 | 36 | 无 | 纳入，作为缓冲余量 |
| — | 需求E 移动端适配 | 12 | 48 | 无 | 超出可承诺规模，退回待办列表 |
取舍理由：需求E规模最大且优先级靠后，纳入后会挤占缓冲，导致依赖延迟时没有调整空间，因此退回。需求D规模小、无依赖，放在最后纳入，为计划保留约2.5人天的余量。范围调整规则写明：需求A的第三方接口延迟超过2个工作日，或需求C的上游交付晚于第8个工作日，由产品负责人决定移除需求D或需求F，迭代负责人当天更新计划并同步相关方。
这份示例的关键在于，每条纳入的需求都能对应到容量数字，每条外部依赖都有时点和对接人，缓冲和调整规则在计划定稿前就已写明。计划执行中，团队通过敏捷看板管理任务状态，在每日站会上对齐进度与风险；燃尽图可以帮助团队观察实际消耗与计划的偏差，为下一次容量核算积累数据。
计划定稿前的完成检查
计划定稿前逐项核对以下条目，全部通过再进入执行。
- 容量是否已扣除休假、支持值班和固定会议，净容量数字是否经团队确认。
- 是否预留了与历史波动相匹配的缓冲，缓冲以少纳入需求或单独留出时间的方式明确体现。
- 每条纳入的需求是否有验收标准和明确负责人，测试人员能否据此编写测试用例。
- 每条外部依赖是否标注了交付时点、对接人和延迟后的应对方式。
- 是否写明范围调整的触发条件和决策人，调整后由谁更新计划、通知哪些相关方。
- 迭代目标是否能用一句话说清，Sprint Backlog中的需求是否都服务于这个目标。
- 未完成工作的处理规则是否明确：迭代结束时未完成的需求重新评估规模和优先级，再决定是否纳入下一迭代，不默认结转。
最后一条容易被跳过。默认结转会让下一迭代的容量在开始前就被占用，计划失去准确性。重新评估意味着把未完成需求放回候选清单，按当时的优先级和最新估算重新参与裁剪，这样每次计划的容量约束都是真实的。
检查通过的标准是：团队每个成员都能说出自己本迭代的主要任务、依赖对象和验收要求；产品负责人能说清范围调整时先砍什么；迭代负责人手里有完整的容量表、依赖清单和调整规则。做到这三点，计划就具备了执行和调整的基础。
常见问题
团队可用容量核算出来之后，如果发现连高优先级需求都装不下，应该先动范围还是先动时间？
先看时间是否真的不可动。迭代周期通常由团队节奏决定，临时延长会打乱后续排期和外部协同，因此多数情况下优先裁剪范围：把高优先级需求按规模从大到小检查，规模大且可以拆分到下一迭代的部分先退回待办列表，保留能形成完整交付的最小集合。
如果高优先级需求本身无法拆分，或者业务时点确实不可推迟，再考虑调整人力或时间，并同步告知相关方。无论选哪种，都要在计划里写明取舍理由，避免迭代中途再次争论。
外部依赖的交付时点晚于本迭代中依赖它的任务开始时间，计划该怎么处理？
这类依赖不适合硬排进本迭代的执行顺序。可以把依赖它的任务排到交付时点之后，同时评估这段时间是否还有不依赖外部条件的任务可以填充；如果填充后仍无法在迭代内完成，就把该需求整体退回待办列表，等依赖明确后再纳入。
另一种做法是保留需求但缩小范围，只做不依赖外部接口的部分。无论哪种处理，都要在依赖清单里写明对接人和最晚到位时间，并约定延迟超过多少天触发范围调整。
缓冲留多少合适，留多了会不会浪费容量？
缓冲比例可以参考团队过去几个迭代的实际完成率波动，例如完成率常在计划规模的九成左右，就按接近一成的比例预留。团队历史数据不足时，先取一个保守的小比例，运行两三个迭代后再校准。
缓冲的作用是吸收估算偏差和偶发阻塞，留得过多确实会降低容量利用率。可以把缓冲体现为少纳入一条低优先级需求，或为高风险事项单独留出时间，并在迭代回顾时检查缓冲是否被实际消耗，据此调整下一次的比例。
迭代结束时未完成的需求，直接放进下一迭代有什么问题？
直接结转会让下一迭代的容量在开始前就被占用，新需求排进来时容易超出真实容量，计划随之失去准确性。未完成需求可能还带着原来的估算，而实际情况已经变化，规模、优先级和依赖条件都需要重新确认。
更稳妥的做法是把未完成需求放回候选清单，重新评估规模和优先级，再和其他需求一起参与下一迭代的裁剪。这样每次计划的容量约束都基于当时的真实条件。
计划评审时三个角色意见不一致，谁来做最终决定？
按决策对象区分。范围取舍的优先顺序由产品负责人决定，包括范围调整时先移除哪条需求；工作量估算和完成定义由开发团队确认，团队认为无法在容量内完成时有权提出异议；容量数字和调整流程由迭代负责人确认并记录。
意见不一致时，回到容量表和依赖清单这些共同依据上讨论，把分歧落到具体数字和条件上。产品负责人和开发团队对范围能否装进容量需要共同确认，任何一方单独承诺都容易在迭代中途失守。
