迭代进行中有人请假，受影响的是剩余可用容量，原始承诺需要据此重新核对。调整时按“重算剩余容量—区分承诺与弹性—重排优先级—同步干系人—记录变更”的顺序推进，把按人头估算的承诺改为按剩余可用工时和关键角色约束重算，并明确哪些事项降级为弹性目标。未完成事项要重新评估，不默认顺延到下一迭代。
要点总览（TL;DR）
- 先按剩余工作日和日有效工时重算容量，把请假折算成可比较的工时缺口，并区分关键角色缺口与可替代缺口。
- 按对外依赖和截止刚性把工作拆成承诺项与弹性项，承诺总量与重算后的剩余容量对齐，超出部分降级或拆分。
- 被挤出的工作按移出、降级、拆分三种方式处置；迭代结束时未完成的工作逐项重新评估，不默认结转到下一迭代。
- 调整由产品负责人确认承诺范围、迭代负责人组织重算与同步、团队成员判断交接可行性，并留下承诺变更记录。
- 调整后用清单核对容量对齐、关键角色缺口处理、干系人同步和记录完整性，并在下一迭代规划时预留缓冲。
先算清请假带来的容量缺口
容量重算的起点是把请假天数折算成团队真正少掉的可用工时，再与迭代剩余天数对照。只报“少了两个人”无法支撑承诺调整，需要落到具体工时和角色。
折算口径与步骤
- 确定请假人天：按工作日计算，扣除请假区间内的周末和团队统一休假日，得到实际缺席天数。
- 折算日有效工时：用团队平时用于迭代交付的净工时，扣除会议、支持、评审等固定占用，得到每人每天的有效投入。这个口径应与迭代开始时估算承诺所用的口径一致，避免前后不可比。
- 计算剩余迭代天数：从请假生效日到迭代结束日之间的工作日，已过去的天数不计入剩余容量。
- 得出缺口：缺口 = 请假人天 × 日有效工时；若请假跨迭代边界，只计入落在本迭代内的部分。
区分关键角色缺口与可替代缺口
同样的人天缺口，影响并不相同。关键角色缺口指该角色承担的工作缺少具备同等技能的人接手，例如唯一熟悉某模块的开发和测试；可替代缺口指团队内有人能在较短时间内接手，代价是挤占其原有任务。判断方法是对每个请假人员列出其在本迭代承担的工作项，逐项标注“仅此人可做”“可交接给某人”“可延后”。关键角色缺口需要优先在承诺范围上做减法，可替代缺口则可以通过任务交接消化一部分。
剩余容量重算表
| 人员 | 本迭代可用天数 | 请假天数 | 日有效工时 | 剩余可用工时 | 角色缺口类型 |
|---|---|---|---|---|---|
| 成员A | 10 | 3 | 6 | 42 | 关键角色，无可替代 |
| 成员B | 10 | 2 | 6 | 48 | 可交接给成员C |
| 成员C | 10 | 0 | 6 | 60 | 需承接交接，实际可用减少 |
| 合计 | — | 5 | — | 150（原为180） | 缺口30工时 |
表格的完成标志是：每个请假人员都有对应的剩余工时和缺口类型，团队总缺口可以用一个数字表达，并且这个数字与迭代开始时承诺所依据的容量口径一致。
把承诺工作量拆成承诺项与弹性项
容量缺口算出来后，直接按比例砍掉所有任务并不可取，因为不同工作项的刚性差别很大。更稳妥的做法是把当前迭代的工作逐项分为承诺项和弹性项，再让承诺总量与重算后的剩余容量对齐。
承诺项的判定标准
满足以下任一条件的工作项，通常应归入承诺项：有对外依赖，例如其他团队或客户按约定时间等待交付；截止时间刚性，例如合规节点、上线窗口、合同约定；不完成会阻塞后续迭代的关键路径。承诺项的数量应控制在剩余容量能够覆盖的范围内，超出部分必须重新讨论，而不是靠加班默认消化。
弹性项与可延后项的划分
弹性项指本迭代希望完成、但延后不影响对外承诺的工作，例如内部优化、体验改进、非紧急缺陷修复。可延后项则是明确可以移出本迭代、留待后续评估的工作。划分时对每个工作项标注“承诺”“弹性”“可延后”三档，并写明判断理由，便于后续复盘时核对判断是否合理。
承诺总量与剩余容量对齐
对齐方法是：先汇总承诺项的估算工时，与重算后的剩余容量比较。承诺项工时超过剩余容量时，按优先级把部分承诺项降为弹性项，或拆分出可在本迭代完成的部分；承诺项工时明显低于剩余容量时，可以从弹性项中补充，但应保留一定缓冲应对交接损耗和不确定性。对齐后的承诺总量应作为本迭代新的对外承诺口径，替换原来的数字。
按优先级重排并处理被挤出的工作
范围划分完成后，需要确定哪些工作先做、哪些被挤出，以及被挤出的工作如何处置。重排的依据应事先说清，避免临时由个人偏好决定。
重排的排序依据
常用排序依据包括：对外承诺的截止时间、对其他团队的阻塞程度、工作项之间的依赖顺序、完成度高低。已经投入较多且接近完成的工作项，通常优先收尾，避免半成品占用容量；依赖链上游的工作项优先安排，防止下游整体等待。排序结果应形成一份新的迭代工作清单，标明顺序和预计完成时间。
被挤出事项的三种处置
- 移出：将工作项移出本迭代，回到待办列表并重新参与后续迭代的优先级排序，不在本迭代保留“挂起”状态。
- 降级：保留在本迭代但降为弹性目标，明确“完成更好、不完成不影响承诺”，并同步给相关干系人。
- 拆分：把工作项拆成可在本迭代完成的部分和留待后续的部分，本迭代只承诺前者，拆分后的子项分别进入对应范围。
未完成工作的重新评估
迭代结束时仍未完成的工作，需要重新评估而不是默认结转。评估判断点包括：该工作是否仍然必要、优先级是否变化、原估算是否明显偏差、剩余部分能否独立成项。重新评估后，必要且优先级高的进入下一迭代的候选范围，不再必要的关闭或退回待办，估算偏差大的补充说明原因。这样处理可以避免未完成工作无声地累积到下一迭代，稀释新迭代的承诺。
角色分工与变更记录
调整涉及重新计算、确认承诺和对外同步三类动作，需要明确由谁负责，并留下可追溯的记录。
职责分工
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 产品负责人 | 依据优先级确定承诺项与弹性项的划分，确认范围调整方案，对外说明承诺变化 | 调整后的承诺清单 |
| 迭代负责人 | 组织容量重算，汇总缺口，主持重排讨论，跟踪调整后的执行情况 | 剩余容量重算表、重排后的工作清单 |
| 团队成员 | 提供任务估算与交接可行性判断，认领调整后的工作，及时反馈风险 | 任务交接说明、进度更新 |
确认与同步动作
调整方案形成后，由产品负责人确认承诺范围，迭代负责人将变更同步给团队和受影响的干系人，包括依赖本迭代交付的其他团队和关注进度的管理者。同步内容应说明调整原因、新的承诺范围和弹性范围、对被移出工作的处置结论。同步应在调整决定作出后尽快完成，避免干系人仍按原承诺安排后续工作。
变更记录字段
承诺变更记录建议包含：变更日期、请假人员与天数、重算前后的剩余容量、被调整的工作项及原承诺状态、调整后的状态（承诺/弹性/移出/拆分）、调整理由、确认人和同步对象。记录的作用是让后续复盘能还原当时的判断依据，也便于下一迭代估算时参考。
在工具层面，这类调整可以借助工作项状态和迭代范围的管理动作落地。ONES 支持产品负责人按优先级将需求规划至对应迭代，并在迭代计划中与团队共同评审；迭代进行中团队通过敏捷看板管理任务状态，在每日站会中对齐进度与风险，燃尽图可用于观察剩余工作量的变化趋势。将请假导致的范围调整反映到工作项状态和迭代范围中，能让变更记录与实际执行保持一致。
一个请假场景的调整示例
以下为演示情景，用于说明推演过程，数字为便于计算的假设值，不代表真实项目数据。
示例输入
某迭代共10个工作日，团队3人，每人日有效工时6小时，原承诺总量180工时。迭代进行到第4天时，成员A请假3天，成员B请假2天。成员A负责支付模块的核心开发，团队内无人可替代；成员B负责的报表页面可由成员C接手，但会占用成员C约8小时。
逐步调整过程
- 重算容量：剩余6个工作日，成员A剩余3天、成员B剩余4天、成员C剩余6天。成员C需分出8小时交接，实际可用约28小时。团队剩余容量约为18+24+28=70工时，原计划剩余容量约为108工时，缺口约38工时。
- 识别关键角色缺口：成员A承担的支付模块开发属于关键角色缺口，其剩余3天无法通过交接补足，相关承诺项需要缩减或拆分。
- 划分承诺与弹性：对外依赖的上线相关功能保留为承诺项，内部优化和部分非紧急缺陷降为弹性项，支付模块中依赖成员A的部分拆分为本迭代可完成的基础部分和后续部分。
- 重排优先级：先完成依赖链上游且接近完成的工作项，成员C在交接后优先处理阻塞他人的任务。
- 同步与记录：产品负责人确认新的承诺范围，迭代负责人同步给依赖该迭代的团队，并记录容量变化、调整项和理由。
调整前后对比
| 项目 | 调整前 | 调整后 |
|---|---|---|
| 可用容量 | 180工时 | 约70工时（剩余部分） |
| 承诺项 | 全部计划工作项 | 对外依赖和刚性截止的工作项 |
| 弹性项 | 无明确划分 | 内部优化、非紧急缺陷等 |
| 被挤出工作 | — | 部分移出、部分拆分、部分降级 |
调整后的完成检查
调整方案落地后，用以下清单逐项核对，确认容量、范围、同步和记录都已到位。
- 容量与承诺是否对齐：承诺项估算工时不超过重算后的剩余容量，并保留合理缓冲。
- 关键角色缺口是否已处理：无可替代的工作已缩减、拆分或调整顺序，未依赖加班默认消化。
- 承诺项与弹性项是否逐项标注：每个工作项都有明确归属和判断理由。
- 被挤出工作是否有处置结论：移出、降级、拆分三种处置均已明确，没有悬空事项。
- 干系人是否已同步：受影响的团队和管理者已知晓新的承诺范围和调整原因。
- 记录是否完整：变更记录包含日期、请假情况、容量变化、调整项、理由和确认人。
- 下一迭代容量是否已预留缓冲：在下一迭代规划时考虑本次请假的影响和交接损耗，避免按满负荷承诺。
- 未完成工作是否已重新评估：迭代结束时对未完成项逐项判断必要性、优先级和估算偏差，不默认结转。
常见问题
请假只影响一两天，还需要重算容量并调整承诺吗？
短时请假同样会减少剩余可用工时，是否调整承诺取决于缺口与缓冲的关系。如果团队在迭代规划时保留了缓冲，且请假人员承担的工作可交接、不处于关键路径，可以只做任务交接并在每日站会跟踪，承诺范围保持不变。如果请假落在关键角色上，或缺口已经超过缓冲，就需要按重算结果调整承诺，避免把缺口留到迭代末期靠加班消化。
关键角色请假、工作无人可替代时，除了砍范围还有别的办法吗？
常见处理有三种：一是缩减范围，把该角色承担的工作中非刚性部分移出本迭代；二是拆分工作项，只承诺本迭代能完成的部分，其余留待后续评估；三是调整顺序，把不依赖该角色的工作前置，等其返岗后再处理关键部分。三种方式可以组合使用。需要避免的是把关键角色缺口默认交给加班或返岗后赶工，这会让承诺重新变得不可信。
被移出的工作要不要直接放进下一迭代？
建议先回到待办列表重新参与优先级排序，而不是直接顺延。判断点包括该工作是否仍然必要、优先级是否因本次调整而变化、原估算是否明显偏差、剩余部分能否独立成项。重新评估后，必要且优先级高的进入下一迭代候选范围，不再必要的关闭或退回待办。这样下一迭代的承诺仍然基于当时的容量和优先级，不会被上一迭代的遗留工作稀释。
承诺范围调整后，需要通知哪些人、通知到什么程度？
至少覆盖两类对象：依赖本迭代交付的其他团队，以及关注进度的管理者。同步内容应说明调整原因、新的承诺范围和弹性范围、被移出或拆分工作的处置结论。同步应在调整决定作出后尽快完成，让相关方按新口径安排后续工作。团队内部则通过站会和看板对齐调整后的任务归属与顺序。
调整过程中可以用工具记录容量变化和承诺变更吗？
可以用工作项状态和迭代范围的管理动作承载调整结果。ONES 支持产品负责人按优先级将需求规划至对应迭代，并在迭代计划中与团队共同评审；迭代进行中团队通过敏捷看板管理任务状态，在每日站会中对齐进度与风险，燃尽图可用于观察剩余工作量的变化趋势。把请假导致的范围调整反映到工作项状态和迭代范围中，变更记录就能与实际执行保持一致。
