迭代管理如何做好迭代容量？产品经理入门指南与操作步骤

迭代计划排得满满当当，到了结束日却只交付了六成：问题往往不是团队“不够努力”，而是计划时把可用工时当成了可承诺容量。做迭代容量规划，我更看重的不是把每个人的日历塞满，而是先算清团队在这段时间里真正能用于交付的工作量，再用历史完成情况校准承诺。本文会从容量口径、计算步骤、案例推演和异常调整讲起，帮助产品经理把“这轮能做多少”从拍脑袋变成可复核的决策。

一、先讲结论：容量不是任务总工时，而是可兑现的团队承诺

1. 先把三个容易混淆的概念分开

可用工时是团队成员在迭代周期内理论上能够工作的时间，扣除假期、培训、值班等已知占用后计算。它描述的是时间边界，并不等于交付能力。

迭代容量是团队在当前人员、技能、协作方式和质量要求下，能够投入迭代工作的有效能力。有效容量通常小于可用工时，因为沟通、代码评审、测试、故障响应和工作切换都会占用时间。

迭代承诺是团队经过估算、依赖确认和风险讨论后，决定纳入本轮目标的工作量。容量是计划上限的依据，不是必须塞满的配额；承诺应留有应对不确定性的余量。

因此，我不会用“团队有 200 小时，就排满 200 小时的任务”来做计划。更可靠的顺序是：先算可用时间，再估有效容量，最后依据历史交付和风险确定承诺。容量回答“最多能承接多少”，承诺回答“这轮愿意负责交付多少”。

2. 用可解释的公式建立容量底稿

对新团队或刚开始做容量管理的团队，我建议从小时口径起步，公式不必复杂，但每个扣减项都要能说清楚：

净可用工时 = 迭代工作日 × 每人每日计划工作时长 − 已知占用工时

计划容量 = 净可用工时 × 专注系数

专注系数不是个人绩效系数，而是团队层面的经验折减，用来覆盖日常协作、临时沟通和无法预先排进日历的工作。团队积累到至少数轮可比较数据后，可以用自己的历史数据替代初始估计。

假设一轮有 10 个工作日，团队 5 人，每人每天按 6 小时计划工作，已知会议、值班和培训合计占用 35 小时，近期专注系数暂按 0.8 估算，那么计划容量为：（10 × 5 × 6 − 35）× 0.8 = 212 小时。这只是容量底稿，不代表应该承诺 212 小时的任务。

3. 把“容量计划”与“目标产出”分开讨论

如果团队把容量理解为“本轮必须做到的工作量”，成员会倾向于在估算时保守不足、在临近结束时降低质量，或者把没完成的工作解释成个人问题。把容量说成预测区间、把迭代目标说成结果承诺，讨论就会更健康。

产品经理应推动团队回答三个不同问题：我们有多少可用时间？按当前条件大概能完成多少工作？为了实现迭代目标，哪些工作必须优先完成？这三者有关联，却不能用一个数字替代。

二、背景和真实场景：为什么计划时看起来充足，执行中却不断缩水

1. 人数没有变，不代表容量没有变

同样是 5 人团队，前一轮可能有完整的两个工作周，后一轮却夹着节假日、发布值班和一位成员休假。即使人数表面不变，净可用工时也可能相差明显。若还沿用“每轮大约做 40 个点”的旧数字，计划从第一天就建立在错误前提上。

容量变化也不只来自假期。新成员需要熟悉代码和业务，资深成员可能要承担评审与指导；某个关键岗位的成员集中处理线上问题，也会让其他人的工作出现等待。人数是输入条件之一，却不是产出的充分解释。

2. 需求交付链条会吞掉“只算开发”的容量

产品需求从澄清到上线，通常会经过设计、开发、评审、测试、验收和发布。若估算时只计算编码时间，测试和联调就会在迭代后半段集中暴露，形成“开发做完了，需求还没交付”的错觉。

我会要求团队先统一工作量口径：估算的是完成定义所需的端到端工作，还是某一个岗位的工作。如果不同任务采用不同口径，容量数字就无法比较。一个故事点若代表完整交付，不能把开发故事点与测试工时混在同一张表里直接求和。

3. 依赖和突发工作会让名义容量失真

等待外部接口、数据权限、设计确认或其他团队排期，不一定消耗大量实际工时，却会占用迭代窗口。任务可能“工时不多”，但由于依赖未解除，无法在目标日期前完成。这种情况不能靠增加一个容量系数解决，应把依赖作为计划风险单独登记。

线上故障、紧急合规要求和客户问题也会争抢团队时间。若这类工作几乎每轮都会发生，就不应继续把它当作偶发事件，而应根据历史占用为支持工作留出容量；若发生频率低但影响巨大，则应准备明确的插入规则和目标调整机制。

4. 迭代容量规划要围绕决策，而不是围绕工具填表

一张容量表的价值，不在于字段多，而在于它能帮助团队做决定：哪些任务现在可纳入，哪些要等依赖确认，哪些必须拆分，哪些需求应被延期。即使团队使用某项目管理工具，若缺少统一口径、完成数据和变更记录，工具也只会把不确定性装进表格。

容量计划的核心产物应是可追溯的假设。例如，团队认为本轮有 212 人时的计划容量，其中 20% 用于常规协作折减，15 人时用于值班，某项外部依赖尚未确认。这些信息比单独写一个“容量 212”更能指导决策。

三、常见误区：看起来精确，实际上会误导计划

1. 误区一：把理论工时当成生产工时

“5 个人、10 天、每天 8 小时，所以有 400 小时容量”是最常见的算术陷阱。8 小时工作日中包含会议、沟通、评审和切换成本；若团队还要承担运维支持，理论值与可投入工作量的差距会更大。

我的处理方式是将个人日历作为上限输入，不把日历空白等同于专注时间。新团队可先用一个明确标注为“待校准”的折减假设，经过几轮回顾后再调整，避免把假设伪装成客观事实。

2. 误区二：用故事点直接推算个人工时

故事点通常用于相对比较工作规模、复杂度和不确定性，不能天然换算成小时。把“一个点等于四小时”作为全团队固定汇率，短期看起来方便，长期容易让估算变成拆工时的另一种形式，也会削弱团队共同估算的意义。

如果团队已经稳定使用故事点，可以用近期团队完成量预测迭代范围，但应保持团队口径一致。若管理需要工时用于排班，可以另做岗位工时估算，不要把两个尺度混为一谈。

3. 误区三：拿最佳一轮的完成量当下一轮基准

一轮偶然完成很多，可能是因为没有线上故障、需求边界清晰、成员熟悉技术方案，或者有工作提前完成但刚好在该轮验收。只看峰值会把偶然条件当作常态，继而连续高估团队能力。

我更愿意观察最近数轮的中位数和波动范围，而不是只看平均数或最高值。中位数对少数异常高低轮次更稳健；波动范围则提醒团队：预测本身有不确定性，不能把一个点数当作绝对承诺。

4. 误区四：计划时把所有人都视为可互换

“总共 200 小时”并不意味着这 200 小时可以任意分配。若任务需要特定领域知识、某项测试只有一位成员能做，或某个关键评审必须由资深成员完成，容量的瓶颈可能出现在某个岗位而不是团队总量。

这种情况下，简单加总会掩盖资源冲突。产品经理要和技术负责人确认关键角色的负荷，识别是否存在单点瓶颈，并优先调整顺序、拆分交付或降低并行工作，而不是继续往总容量里加数字。

5. 误区五：承诺率低就归咎于估算不准

承诺落空不一定因为团队估算差。需求中途变化、依赖延期、优先级频繁调整、质量问题返工，都可能让原计划失效。若只比较“承诺点数”和“完成点数”，却不记录变更原因，就无法知道该改估算、改流程还是改治理方式。

复盘时我会区分计划内未完成、计划外插入、需求范围变化、外部等待和质量返工。不同原因对应不同动作：范围变化要治理变更，等待要管理依赖，返工要补质量环节，估算偏差才需要重新校准预测。

四、专业判断逻辑：从“能做多少”推到“该承诺多少”

1. 先判断数据是否可比，再讨论历史速度

历史完成量只有在迭代长度、团队组成、工作口径和质量门槛相近时，才适合用于预测。若团队上轮按故事点统计，这轮改为人时；或上轮需求含大量维护工作，这轮全部是新功能，直接比较总量会得出错误结论。

我会给每一轮数据附上简短标签：团队人数变化、节假日、重大故障、临时插单、需求类型变化。标签不必复杂，但能帮助判断某轮是否适合作为预测样本。没有可比数据时，宁可明确说“目前只能做初始估计”，也不要制造精确感。

2. 用滚动区间替代单点预测

如果近 5 轮团队完成量分别为 32、36、34、25、39 个点，中位数为 34。25 点那轮若因重大线上故障明显异常，团队可以同时报告“常态预测约 34 点”和“含突发风险的下行情景约 25 点”，而不是只取最高值 39 点作为目标。

区间预测适合回答不同风险偏好下的计划问题：基础目标以更稳妥的完成量制定，扩展候选项则在早期完成且质量达标时再启动。产品经理因此可以把确定性交付与可选工作分开，避免在迭代中后段临时讨论该删哪项。

3. 评估风险时，关注“发生概率 × 影响”，而非只看工时

一个 4 小时的小任务，如果是发布前必须通过的安全检查，风险影响可能高于一个 20 小时但可延期的界面优化。容量规划不应只按任务大小排序，还要识别阻塞迭代目标的关键路径、外部依赖和不可逆的发布日期。

我常用一个简单的三档讨论：低风险是团队熟悉且依赖已具备；中风险是工作量尚可估但存在一项待确认条件；高风险是技术方案、验收口径或外部资源未确定。高风险项应先做澄清或探测任务，不宜直接按完整功能工作量塞入承诺。

4. 预留空间要有依据，不要把缓冲变成隐形浪费

缓冲不是“少做一点”，而是对不确定性做显式安排。若团队常规工作中有固定值班、客户支持或发布任务，应先从容量中扣除；若突发事项较少但难预测，可以按历史占用比例设置风险预留，并在回顾时核对预留是否长期过高或过低。

例如，假设近 6 轮中临时支持分别占计划容量的 5%、8%、12%、4%、15%、6%，团队可以讨论是否按近期分布为支持工作预留空间。这个例子只说明计算思路，实际预留比例应来自团队自身记录，而不是照搬某个通用数字。

5. 让目标、范围和容量之间保持可调整关系

迭代目标是团队优先保护的结果，范围是达成目标的具体工作组合，容量是当前条件下的资源边界。若容量下降，优先保目标、调整范围；若目标本身受外部条件影响，则重新评估目标与时间，不应只通过压缩测试或延长工作时间维持原计划。

这条判断能避免常见的错误路径：先承诺全部需求，再通过加班弥补低估。合理的容量管理不是保证计划永远不变，而是让计划变化有依据、有顺序、有记录。

五、具体操作步骤：在迭代计划会上把容量算清楚

1. 会前收集五类输入

容量计划不应在会议现场临时猜。产品经理可以提前收集人员日历、迭代工作日、已知会议与值班、近期团队完成数据、未解决的跨团队依赖。输入不需要一次做到完美，但要把来源和假设写明。

• 确认本轮起止日期及实际工作日，标出节假日和发布窗口。
• 确认团队成员及岗位变化，包括休假、入职、轮岗和培训安排。
• 统计确定会发生的值班、支持、评审和组织会议占用。
• 整理近 3 至 6 轮的完成量、未完成原因和计划外工作。
• 列出关键外部依赖、待确认事项与预计确认日期。

如果团队过去没有记录，不必停下来先建设复杂报表。可以从这一轮开始留存每人可用天数、计划内工作、临时插入和最终完成情况，用同一套口径连续记录几轮后再做校准。

2. 计算个人可用时间，但避免把个人数字做成排名

逐人统计可以发现休假和岗位瓶颈，但不能把净工时直接解释为个人产出目标。容量管理关注的是团队如何组合工作，不是给成员按小时分配压力。对外呈现时可以汇总团队容量，对内讨论时再识别必要的技能和排期约束。

例如，一名测试成员休假 3 天并不只是减少该成员 18 小时，也可能导致测试队列延长。团队需要同时讨论工作流影响：哪些需求可以提前验证，哪些工作必须由其他成员协助，哪些交付应降低并行数量。

3. 估算工作时，先保证“完成定义”一致

对每项候选工作，团队应确认需求边界、验收条件、依赖和完成定义。如果工作还缺少关键决策，先列为澄清项或技术探测项，不要为了凑容量而给一个看似精确的点数。

容量会议中，产品经理负责解释用户价值、优先级和验收结果；工程团队负责估算实现与质量工作；测试、设计或运营角色应在其工作进入迭代时参与估算。估算不是产品经理单方面分派工时。

4. 先保护迭代目标，再纳入候选工作

建议先选出实现迭代目标必需的工作，再加入次优先级候选项。若必需工作已经接近容量边界，应暂停继续加需求，先确认拆分、依赖、风险和可延期部分。把整个待办列表从高到低塞进迭代，容易造成目标失焦。

候选项可以分为“承诺项”和“备用项”。承诺项经过依赖确认并纳入目标；备用项在容量富余、风险解除且质量标准不受影响时才启动。备用项不能被当作隐形承诺，否则团队仍会承受超载压力。

5. 在会议上做一次负荷与风险检查

工作量总和看起来合理，不代表工作分配合理。团队要检查关键岗位是否过载、同一成员是否同时负责过多并行任务、评审和测试是否集中到迭代末尾，以及依赖是否有明确负责人和截止时间。

我会在结束前逐项确认：本轮目标是什么？哪些工作是达到目标的必要条件？若临时插入一项紧急任务，优先移出什么？出现阻塞时由谁协调？这些问题比“总点数是否填满”更能检验计划是否可执行。

6. 迭代中记录变化，不要等结束后凭印象复盘

每次发生插入、范围变化、依赖延期或故障，都记录发生时间、影响工作和调整决定。记录不必写成长篇报告，关键是能区分计划初始状态与执行后的变化。否则，结束时的完成量无法解释为什么偏离原计划。

如果团队使用某项目管理平台，可以用统一字段记录变化原因、计划内外属性和阻塞状态；如果暂时没有合适的配置，一张共享表也足以起步。工具选择应服务于可追溯，而不是先追求复杂自动化。

7. 迭代结束后更新预测，而不是给团队打分

回顾时比较计划容量、原始承诺、最终完成、计划外工作和质量结果。若完成量偏低，先按原因分类，再判断是容量估计、优先级稳定性、依赖管理还是质量流程的问题。只有原因明确，下一轮的调整才有方向。

至少连续几轮使用同一口径后，团队才适合讨论专注系数、预留比例或预测区间是否要调整。单轮数据受偶然因素影响很大，不宜因为一次高低就大幅改变基准。

六、案例推演：一个五人团队如何把容量从“约 40 点”变成可讨论的计划

1. 先说明案例边界，避免把示意数据误当行业结论

下面是一个匿名化的情景推演，用来演示计算与判断方式，不是某家企业的实测成绩，也不代表所有团队都应达到相同速度。团队由 1 名产品经理、3 名开发成员和 1 名测试成员组成，迭代为 10 个工作日。

近 5 轮团队完成量为 32、36、34、25、39 个故事点，中位数 34 点。第 4 轮因线上故障处理出现明显下滑。团队之前习惯把每轮计划定在约 40 点，结果常常留下未验收工作；这次计划会决定同时看故事点趋势和人时约束，而不是只沿用最高完成量。

2. 逐步计算本轮可用容量

5 名成员按每天 6 小时计划投入迭代工作，10 个工作日得到 300 人时理论工作时长。已确认的评审、值班和培训合计占用 35 人时；团队依据近期记录暂用 0.8 的专注系数，折算后计划容量约为 212 人时。

这 212 人时不是所有工作的统一上限，因为测试与开发岗位并不能完全互换。测试成员本轮有 1 天培训，关键集成测试需要由其完成；因此团队还单独检查测试队列，提前安排高风险接口验证，而不是等开发全部结束后再集中交付测试。

3. 用目标拆分出承诺项和备选项

本轮目标是让用户能够完成一条新的自助申请流程。团队将工作拆成申请表单、权限校验、状态回显、测试与发布检查等若干可验收项。两个外部接口中，一个已确认，一个仍待对方提供测试环境，因此团队没有把后者的完整接入作为无条件承诺。

计划会最终选择 7 项核心工作作为承诺项，合计估算 31 个故事点；另有 2 项合计 5 个点作为备选。31 点低于过去五轮中位数 34 点，差额不是“浪费”，而是考虑本轮测试瓶颈及未确认依赖后做出的风险取舍。

4. 设定清楚的触发条件和调整顺序

团队约定：如果接口环境在迭代第 3 个工作日之前准备好，且核心流程通过第一次联调，可以评估启动一项 3 点的备选工作；否则备选项不进入本轮。若出现紧急线上问题，先保留用户申请主流程，将低优先级的状态优化移出，并同步告知相关方。

这个安排的价值在于，计划变化不再靠临时争论。何时启动备选、发生故障时先让出什么、谁负责确认接口条件，都已经成为可执行规则。容量规划因此从一张静态清单，变成了有条件、有顺序的决策方案。

5. 复盘时既看完成，也看计划质量

假设这轮完成 30 个承诺点，接口环境晚到两天，团队没有启动 3 点备选项，同时有一项 2 点工作因验收发现边界问题未完成。仅看“完成 30、承诺 31”，会把计划描述成接近达成；更重要的是确认主流程是否可用、未完成项是否影响目标、接口等待是否得到及时升级。

若主流程按验收标准交付，团队可以认为迭代目标达成，但应把边界问题作为后续改进项；若未完成项导致主流程无法使用，就不能用较高的完成比例掩盖目标失败。容量预测的质量最终要通过用户价值和交付质量验证，而不是只通过点数验证。

七、不同团队阶段的行动建议：先解决当前最影响预测的问题

1. 新团队或数据不足的团队

新团队通常没有稳定的历史速度，不建议为了做出精确预测而临时发明换算比例。先按成员日历计算净可用工时，选择少量高优先级工作，记录估算、阻塞、计划外支持和完成结果。

前几轮的目标是建立共同口径，而不是追求容量数字漂亮。每轮都用相同定义记录“完成”，经过几轮后再观察团队自己的波动、专注情况和岗位瓶颈。

2. 稳定团队且交付数据较完整的团队

稳定团队可以结合历史完成量、迭代长度和异常标签做区间预测。建议准备基础目标与备选范围：基础目标对应较稳妥的交付组合，备选工作则有明确启动条件。不要因为数据较多就误以为未来确定，需求复杂度和外部条件仍可能变化。

如果团队长期存在相似的支持工作，可以把它作为容量结构的一部分，而不是每轮临时“借用”产品工作时间。将常规支持、产品交付和技术改进分开观察，有助于判断容量究竟花在了哪里。

3. 频繁承接线上支持的团队

对支持型团队，应先区分可预测的值班工作与不可预测的突发事件。固定值班按排班扣减；突发事件则根据历史占用留出风险空间，并准备优先级与移出规则。若突发工作长期挤压产品目标，问题可能不是容量计算，而是支持职责与产品职责没有合理分流。

复盘时要统计支持请求次数、处理人时、严重程度及其对迭代的影响。请求数量很多但单次处理很短，与低频但高影响的事故，需要不同的资源安排策略。

4. 跨团队依赖较多的团队

跨团队依赖不宜只写一句“等待对方”。应明确依赖内容、联系人、需要日期、最迟决策点和失败后的替代方案。对于关键依赖，团队可以先安排接口验证、契约确认或小规模探测，尽早降低不确定性。

如果依赖方无法承诺时间，产品经理就要在目标层面做取舍：选择不依赖该资源的替代交付，拆成可独立完成的阶段，或者调整对外日期。把风险留在计划备注里却不调整范围，等于没有真正管理风险。

5. 角色技能集中或关键成员不可替代的团队

若某岗位只有一名成员能完成关键工作，团队容量由这个岗位的瓶颈决定。可采取结对、知识交接、评审轮换和任务拆分等方式降低集中度，但不要假定短期培训能立刻把其他人的能力变成等价替代。

短期内无法消除瓶颈时，应把关键工作提前安排，限制同时进行的任务数，并在计划中明确该成员的评审和支持负荷。总体人时充足，不能抵消关键角色的排队时间。

八、不同情况下的取舍：容量不足时，先动范围，不要先牺牲质量

1. 优先级冲突时，保目标还是保清单

当本轮需求多于容量，优先保住能够形成可验证用户价值的目标，而不是机械保住最初的需求清单。若多个需求都声称“最高优先级”，产品经理应依据用户影响、业务时限、风险和依赖成本重新排序，并明确哪些请求被推迟。

有明确发布日期或合规要求时，团队可能需要优先保障硬约束，但要同步缩小非必要范围。若没有硬截止日期，宁可拆成阶段交付，也不要为了清单完整而把验收和质量工作压到最后。

2. 临时插单时，选择替换而不是叠加

临时工作确实可能比原计划更重要，但“重要”不意味着容量凭空增加。产品经理应推动决策者说明插入工作的价值和时限，再从现有范围中移出相应工作，记录被替换的项目和对迭代目标的影响。

如果团队每轮都接受插单却不调整原承诺，最后的完成率就失去意义，也会形成“任何工作都能追加”的错误预期。例外可以存在，但例外需要可见、可解释。

3. 质量要求与短期交付冲突时，避免用隐性成本换表面完成

减少测试、跳过必要评审或降低验收标准，短期可能让完成数字上升，却可能把成本转移到返工、缺陷和线上事故。只有在风险被明确评估、责任人知情且后续补救安排清楚时，团队才适合讨论质量范围的调整。

更好的首选通常是减小交付范围、拆分需求或延后非核心工作。质量不是容量不足时默认可以削减的余项，而是决定“完成”是否成立的条件。

4. 团队长期超载时，先找结构性原因

如果团队连续多轮承诺超过实际完成，且每轮都靠加班或牺牲质量弥补，继续压低单项估算并不能修复系统性问题。应检查需求进入节奏、未完成工作积压、岗位瓶颈、技术债、依赖等待和支持职责分配。

容量下降有时意味着团队正在承担更多隐性工作，而不是成员效率降低。管理者需要据此调整工作入口、技术投入或团队职责，产品经理则应提供可量化的影响记录，帮助组织做优先级决策。

九、复盘与持续改进：让容量预测逐轮变得更可信

1. 建立一张最小可用的容量记录表

记录表不需要包含所有可能字段。对于多数团队，先保留迭代周期、成员可用天数、已知占用、初始容量、原始承诺、实际完成、计划外工作、未完成原因和质量结果，就已经足以支撑基础复盘。

重要的是定义一致。例如，“实际完成”应以通过团队完成定义为准，而不是以代码提交、开发自测或进入测试环境为准。不同团队可以设置不同完成定义，但一旦开始比较趋势，就不应随意更换口径。

2. 复盘时看预测偏差，也看偏差来源

可以观察承诺工作完成比例、计划外工作占比、外部等待时间、返工工作量和关键岗位负荷。这些指标不是用来给个人排名，而是用于定位系统问题。若只看完成比例，团队可能通过减少承诺或降低质量制造更好看的数字。

例如，完成比例从 70% 上升到 90%，但计划外支持同时增加、缺陷返工也变多，不能简单认定容量预测变好了。需要把交付结果、质量和工作类型放在一起看，判断改善是否真实且可持续。

3. 每次只调整少数关键假设

如果本轮发现专注系数偏高，不要同时改变迭代长度、估算尺度、完成定义和人员配置，否则下一轮无法知道哪项调整带来了变化。先选最有证据支持的假设，更新后观察几轮，再判断是否继续调整。

容量治理不是追求一套永远正确的公式，而是逐步减少计划中不可见的部分。团队知道哪些工作会打断、哪些岗位会排队、哪些依赖会延迟，就已经比一个看似精确但无人信任的数字更接近有效管理。

4. 用预测服务协作，而不是把容量变成绩效指标

若容量数字被用于个人考核，成员很容易通过提高估算、减少协作或选择低风险任务来保护自己。团队数据应优先服务于计划与资源决策，而非简单归因于个人效率。

管理者可以用趋势讨论团队是否需要减少并行工作、补齐关键技能或调整需求入口。个人层面的辅导应基于具体协作和质量反馈，不应把团队整体完成量直接拆分成个人产能配额。

十、结语：把容量当作一项可校准的经营判断

做好迭代容量，不是找到一个适用于所有团队的神奇公式，而是建立一条可解释的判断链：从人员日历和已知占用出发，用真实交付记录校准预测，再把依赖、风险和质量要求纳入承诺讨论。容量数字越能说明来龙去脉，计划就越能在变化面前保持可信。

我认为最值得坚持的一条原则是：当需求超过容量时，先让取舍显性化；当预测偏离时，先找系统原因；当数字看起来精确时，先问它是否基于可比数据。不要用加班掩盖容量假设，不要用点数掩盖依赖，也不要用完成率掩盖质量。

下一步可以从最近三轮迭代开始：统一“完成”的定义，补记计划外工作和未完成原因，按成员日历计算下一轮净可用时间，并将承诺项与备选项分开。先做出一份能被团队共同解释的计划，再逐轮校准参数。容量管理真正成熟的标志，不是每轮都猜中同一个数字，而是团队知道偏差从哪里来、该调整什么，以及如何在不牺牲质量的前提下重新承诺。

常见问题解答（FAQ）