迭代结束时，未完成工作并不都需要重评。重评要回答的是“这些工作是否仍值得继续投入”：当需求前提已变化、验收口径待确认、剩余工作量与原估算明显偏离、跨团队依赖尚未就绪，或该项已不再服务当前迭代目标时，适合逐项重评；当迭代目标稳定、剩余工作清晰、依赖已就绪时，直接结转更省成本。重评本身需要评审时间和信息准备，应按项筛选，避免变成所有未完成项的固定动作。
要点总览（TL;DR）
- 迭代未完成工作重评适用于需求前提变化、验收口径待确认、剩余工作量与原估算明显偏离、跨团队依赖未就绪，或该项已不再服务当前迭代目标的情况。
- 重评要回答的是未完成工作是否仍值得继续投入，结转只是处理结果之一；目标稳定、剩余工作清晰、依赖已就绪时，直接结转更省成本。
- 重评需要产品、开发、测试在迭代边界投入评审时间，并保留原估算、变更记录和依赖状态作为判断依据，结论要落到工作项状态与下一迭代计划。
- 迭代目标本身需要重新规划或信息不足以判断时，应先处理目标问题或补齐变更与依赖信息，再安排重评。
- 验证重评是否有效，可先在一个迭代内限定范围试点，观察结转项返工情况、下一迭代计划贴合度和评审能否按时形成结论。
先给结论：哪些未完成工作值得重评
重评的对象是未完成工作的继续投入价值，结转只是处理结果之一。团队在迭代边界先判断“继续做是否仍然成立”，再决定这项工作进入下一迭代、退回待办、拆分调整还是关闭。把重评等同于结转，容易让已经失效的工作继续占用下一迭代容量。
以下情形适合纳入重评：需求前提发生变化，原方案已不适用；验收口径存在争议或需要重新确认；剩余工作量与原估算明显偏离，继续投入的规模需要重新判断；跨团队依赖尚未就绪，短期内无法按原计划推进；该项已不再服务当前迭代目标，优先级需要重新排序。
以下情形可以直接结转：迭代目标未变，未完成项的剩余工作清晰，依赖已就绪，负责人和验收标准明确。此时重评增加的评审动作难以带来新的判断信息，直接带入下一迭代并保持原有跟踪方式更省成本。
| 判断维度 | 适合重评 | 可以直接结转 |
|---|---|---|
| 需求前提 | 需求已变更或方案前提不成立 | 需求内容与范围保持稳定 |
| 验收口径 | 验收标准有争议或需要重新确认 | 验收标准明确且团队无异议 |
| 剩余工作量 | 与原估算明显偏离 | 剩余工作清晰、规模可预期 |
| 依赖状态 | 跨团队依赖未就绪 | 依赖已就绪或不受外部阻塞 |
| 迭代目标 | 该项已不服务当前目标 | 仍属于下一迭代目标范围 |
重评要解决的问题与价值机制
迭代结束时，未完成项往往处于信息不完整状态。需求可能在迭代中途被调整，原估算可能因为技术方案变化而失真，依赖方的交付时间也可能已经改变。如果这些信息没有被重新确认，未完成项会带着旧假设进入下一迭代，团队按过时信息安排容量和优先级。
重评围绕四个判断动作展开：重新确认工作范围，明确这项工作的边界是否仍然成立；重新确认验收标准，让产品、开发和测试对“完成”有一致理解；重新估算剩余工作量，用当前信息替代原估算；重新判断优先级，确认它是否仍应占据下一迭代的容量。
这些动作的价值体现在两个结果上：一是减少无效投入，让已经失效或价值下降的工作及时退出或调整；二是让下一迭代计划建立在真实信息上，容量安排、依赖协调和目标承诺有更可靠的依据。重评不承诺具体的效率提升数字，它的作用是改善判断质量，效果取决于团队执行的信息完整度和决策效率。
适用条件：团队与工作项满足什么前提
重评能否产生判断价值，取决于团队和工作项两个层面的前提是否具备。
团队层面的前提
- 迭代有明确目标。团队能够说清本迭代要达成什么结果，才能判断未完成项是否仍服务该目标。
- 有稳定的评审节奏。迭代结束时有固定的计划或评审会议，产品、开发、测试角色能够共同参与。
- 有可做决策的角色。重评会涉及范围调整、优先级变化和是否关闭的判断，需要产品负责人或相应决策者在场。
工作项层面的前提
- 存在可核查的变化信号，例如需求文档已更新、依赖方交付时间已变更、验收标准在评审中出现分歧。
- 原估算和当前进展可以对照，团队能够说明剩余工作与原估算的差异在哪里。
- 该项与迭代目标的关联可以重新说明，而不是仅凭“已经做了一部分”继续保留。
条件不满足时，重评容易流于形式。团队缺少目标依据，评审会变成逐项表态；缺少变化信号，重评只是重复原计划；缺少决策角色，结论无法落地。此时应先补齐目标说明或变更信息，再决定是否重评。
投入与前提：重评需要付出什么
重评是一项有成本的管理动作，团队需要为它投入时间、角色和信息准备。
时间投入集中在迭代边界。团队需要在迭代结束到下一迭代计划之间安排评审时段，逐项讨论需要重评的未完成工作。按项筛选后，评审范围可控；如果对所有未完成项逐一重评，会议时间会随项数增加而上升。
角色投入涉及产品、开发和测试。产品角色确认需求前提和优先级，开发角色说明技术方案与剩余工作量，测试角色确认验收标准和已完成的验证情况。缺少任一角色，重评结论都可能缺少关键依据。
信息准备是重评的前置条件。团队需要保留原估算、变更记录和依赖状态，作为判断“变化在哪里”的依据。原估算用于对照剩余工作量，变更记录用于确认需求前提是否改变，依赖状态用于判断外部阻塞是否解除。这些信息如果在迭代过程中没有记录，重评时只能依赖回忆，判断质量会下降。
重评结论要落到工作项状态和下一迭代计划中。决定继续的工作项应更新范围、估算和负责人，进入下一迭代；决定退回或关闭的工作项应更新状态并说明原因；需要拆分的工作项应形成可独立跟踪的子项。结论不落到状态和计划上，重评就只是讨论，无法影响后续执行。
在工具承载层面，重评涉及的工作项状态更新、迭代规划和进度跟踪需要有统一的位置。ONES 支持团队围绕需求、工作项、迭代和项目进度开展协作，成员可以了解当前工作、优先级和交付目标；团队也可结合自身节奏规划迭代、安排工作事项并跟踪推进状态。重评结论确定后，更新后的工作项和下一迭代安排可以在同一协作环境中衔接，减少结论与执行之间的信息断点。
暂缓条件：什么情况下先不重评
重评不是迭代收尾的必选动作。以下情况适合暂缓，把精力放在更前置的问题上。
- 剩余工作清晰、依赖已就绪、目标未变。此时未完成项的信息完整，直接结转并保持原有跟踪方式更省成本。
- 迭代目标本身需要重新规划。如果市场变化或业务优先级调整导致整个迭代目标不再成立，应先处理目标层面的重规划，再判断单项工作的去留。逐项重评无法替代目标调整。
- 信息不足以判断。需求变更尚未确认、依赖方尚未给出明确时间、验收标准争议还没有结论时，重评容易得出模糊结论。团队应先补齐变更与依赖信息，再安排重评。
暂缓不等于忽略。团队可以记录暂缓原因和需要补齐的信息，设定下一次判断的时间点，避免未完成项在缺乏判断的情况下长期滞留。
试点判断：如何小范围验证重评是否有效
重评是否适合团队，可以通过一个迭代的小范围试点来验证，而不必一次性铺开到所有未完成项。
试点范围建议限定在一个迭代内，并只对特定类型的未完成项重评，例如仅对估算明显偏离或依赖未就绪的项启动重评。这样既能观察重评的判断效果，也能控制评审时间投入。试点前明确参与角色、评审时段和信息准备要求，让每次重评都有可对照的依据。
观察点可以放在三个方向：重评后结转的工作项在下一迭代中是否减少了返工和范围反复；下一迭代的计划容量是否更贴近实际执行情况；评审会议是否能在预定时间内形成明确结论。这些观察点用于判断重评是否带来了更好的判断信息，不以单一数字作为成功标准。
推进条件需要提前设定。如果试点中重评结论能够顺利落到工作项状态和下一迭代计划，且团队认为评审投入与判断质量相匹配，可以逐步扩大重评范围，例如增加适用的未完成项类型。如果重评频繁因信息不足而无法形成结论，或评审时间明显挤占计划会议，应缩小范围，先改善变更记录和依赖跟踪，再重新评估。试点结束后，团队应复盘一次：哪些项的重评改变了原结转决定，哪些项的重评没有产生新信息，据此调整下一轮的筛选规则。
常见问题
迭代结束时所有未完成工作都要重评吗？
不需要。重评适合存在可核查变化信号的未完成项，例如需求前提已变、验收口径有争议、剩余工作量与原估算明显偏离、依赖未就绪，或该项已不再服务当前迭代目标。剩余工作清晰、依赖已就绪、目标未变的项可以直接结转，保持原有跟踪方式。
按项筛选能控制评审时间投入，也避免重评变成所有未完成项的固定动作。
重评结论形成后，团队应该怎么处理未完成工作项？
结论要落到工作项状态和下一迭代计划上。决定继续的项应更新范围、估算和负责人，进入下一迭代；决定退回或关闭的项应更新状态并说明原因；需要拆分的项应形成可独立跟踪的子项。如果结论只停留在讨论层面，未完成项会带着旧信息继续流转。
在工具承载上，ONES 支持团队围绕需求、工作项、迭代和项目进度开展协作，重评后的工作项更新与下一迭代安排可以在同一协作环境中衔接。
迭代目标整体发生变化时，还适合逐项重评未完成工作吗？
这种情况下应先处理目标层面的重规划，再判断单项工作的去留。整个迭代目标不再成立时，逐项重评无法替代目标调整，容易得出零散结论。团队可以先明确新的目标方向，再按新目标筛选哪些未完成项仍值得继续投入。
目标调整完成后，重评的判定标准会更清晰，评审也更容易形成一致结论。
团队缺少变更记录和依赖状态信息，还能开展重评吗？
可以开展，但判断质量会受影响。重评需要对照原估算、变更记录和依赖状态，确认变化发生在哪里。这些信息缺失时，团队只能依赖回忆，容易得出模糊结论。
更稳妥的做法是先补齐关键信息，例如确认需求变更内容、向依赖方获取明确时间、澄清验收标准争议，再安排重评。日常迭代中保留估算和变更记录，也能降低后续重评的信息准备成本。
试点重评时，什么情况下应该缩小范围或暂停？
如果重评频繁因信息不足无法形成结论，或评审时间明显挤占下一迭代计划会议，说明当前范围过大或前置信息不足，应缩小重评范围，先改善变更记录和依赖跟踪。
反之，如果重评结论能顺利落到工作项状态和下一迭代计划，团队也认为评审投入与判断质量相匹配，可以逐步增加适用的未完成项类型。试点结束后复盘一次，看哪些项的重评改变了原结转决定，据此调整下一轮筛选规则。
