迭代未完成工作重评，指迭代结束时对未完成事项逐项重新评估，判断它是否仍值得继续做、以什么状态回到待办、是否需要拆分或关闭。判定标准围绕四点：事项是否仍符合当前迭代目标与产品方向、剩余工作是否已明确到可执行、优先级与投入是否仍成立、延期原因是否已消除。四项都成立才进入重评后继续排期；任一项不成立，就应拆分、降级或关闭。
要点总览（TL;DR）
- 重评判定围绕四条标准：事项仍符合迭代目标与产品方向、剩余工作已明确到可执行、优先级与投入仍成立、延期原因已消除；四项全部成立才进入继续排期。
- 任一条标准不成立，就按对应方向处理：拆分、降级回需求池或关闭，而不是整体结转到下一迭代。
- 重评只处理本次迭代的未完成事项，与需求池管理、Backlog 梳理和重新排优先级分工不同。
- 重评在迭代收尾、下一迭代规划前触发，由产品负责人、团队成员和迭代负责人按职责分工判断并逐项记录去向。
- 判定结论要记录事项标识、逐项判断结果、最终去向和责任人，便于下一迭代规划与回顾追溯。
重评判定看哪几条标准
重评判定要回答的核心问题是：这件未完成的事，还值不值得占用下一迭代的容量。四条标准分别从价值方向、可执行性、投入合理性和风险可控性四个角度给出判断依据，需要逐项对照，不能凭整体印象打包决定。
| 判定标准 | 要回答的判断问题 | 成立时的处理 | 不成立时的处理 |
|---|---|---|---|
| 仍符合当前迭代目标与产品方向 | 这件事服务的业务目标是否仍然存在？产品方向是否已经调整？ | 保留在候选范围，进入后续三项判断 | 关闭或降级回需求池，等待方向明确后再评估 |
| 剩余工作已明确到可执行 | 剩余部分是否已拆到团队能直接领取并开工的粒度？验收条件是否清楚？ | 可以给出剩余工作量估计 | 先拆分或补充说明，暂不排入下一迭代 |
| 优先级与投入仍成立 | 与其他待办相比，它的优先级是否仍排得上？投入产出是否仍合理？ | 进入下一迭代排期候选 | 降级，让位给更高优先级事项 |
| 延期原因已消除 | 导致本次未完成的阻塞是否已解除？外部依赖、资源缺口是否已有安排？ | 可以按正常节奏继续推进 | 保留待办但标注阻塞，或关闭并记录原因 |
四条标准全部成立，事项才进入重评后的继续排期；任一项不成立，就按对应方向处理：拆分、降级或关闭。这里的关键在于逐项判断，而不是给事项打一个笼统的“继续/不继续”标签。例如剩余工作已明确、优先级也成立，但延期原因是关键依赖方尚未交付，那么正确结论是保留待办并标注阻塞条件，而不是直接排进下一迭代再延期一次。
四条标准之间存在先后关系。价值方向不成立的事项，无需再讨论剩余工作是否明确；可执行性不成立的事项，即使优先级很高，也应先拆分再排期。按这个顺序判断，可以减少收尾会上的反复讨论。
重评与默认结转的边界
重评的对象是本次迭代内未完成的事项，结论是逐项重新评估后的去向。默认结转则是把未完成事项整体平移到下一迭代，事项的状态、优先级和拆分粒度都不变。两者的差别在于：默认结转假设“没做完就该继续做”，重评要求先证明“还值得继续做”。
默认结转的问题在于，它把上一迭代的规划决策原样带入下一迭代，而不检查这个决策的前提是否还成立。迭代期间产品方向可能调整、依赖可能变化、优先级可能被新信息推翻。未经重评直接结转，下一迭代的容量会被历史遗留事项占满，团队失去按当前价值重新分配资源的机会。未完成事项越多，这种累积效应越明显。
重评也不等同于重新排优先级。重新排优先级属于需求池管理和 Backlog 梳理的范畴，处理的是全部待办事项的相对顺序，通常在迭代规划前进行。重评只处理本次迭代的未完成事项，产出的是这些事项的去向结论：继续排期、拆分后继续、降级回需求池或关闭。降级回需求池的事项，其后续排序由需求池管理流程接手，不在重评环节决定。
同样，重评不覆盖已完成事项的验收与质量判断，也不替代迭代回顾中对流程问题的讨论。它聚焦于未完成事项的处置，范围限定在本次迭代的遗留工作之内。
重评在迭代收尾中如何运转
重评通常在迭代结束、下一迭代规划开始之前触发，作为收尾工作的一部分完成。这个时点的选择有实际考虑：此时本次迭代的实际完成情况已经确定，下一迭代的容量尚未分配，重评结论可以直接作为规划输入。
参与角色按判断职责分工。产品负责人判断事项是否仍符合迭代目标与产品方向，以及优先级是否仍成立；团队成员判断剩余工作是否已明确到可执行，并给出剩余工作量估计；迭代负责人组织重评过程，逐项记录结论并确认去向。三个角色各管一段判断，避免由单一角色对全部标准拍板。
重评的输入信息包括：事项当前状态、剩余工作的具体说明、本次未完成的原因、以及下一迭代的容量预期。缺少延期原因记录时，第四项标准无法判断，因此迭代过程中的阻塞记录需要在收尾前补齐。
产出是每个未完成事项的一条去向结论，对应四种状态：继续排期、拆分后继续、降级回需求池、关闭。结论应逐项记录，注明依据和责任人，便于下一迭代规划时追溯，也便于后续复盘时核对当初的判断是否成立。
在工具承载上，ONES 敏捷研发管理解决方案覆盖需求池管理、迭代规划、迭代开发、迭代进度跟进、迭代回顾等场景，团队可以围绕项目计划、工作项和迭代安排协同工作，及时了解任务状态和待处理事项。重评结论的记录与去向交接，可以依托工作项状态和迭代安排来完成；迭代完成并发布后，还可以通过燃尽图、工时日志等报表复盘进度偏差，为下一轮重评提供参考。重评的判定规则本身属于团队管理约定，需要团队在流程中明确。
一个判定示例与常见误解
假设某迭代中有一项“订单导出支持按自定义字段筛选”未完成。逐条判定如下：
- 价值方向：该功能仍服务于本季度的报表能力目标，产品方向未调整，标准成立。
- 可执行性：剩余工作是筛选条件配置界面和导出逻辑两部分，验收条件已写明，但配置界面的交互稿尚未确认，标准不成立。
- 优先级与投入：与下一迭代候选事项相比仍排在前列，标准成立。
- 延期原因：本次未完成是因为交互稿评审延迟，该评审已排入下周，原因可消除，标准成立。
四项中有一项不成立，结论是拆分后继续：先完成导出逻辑部分并排入下一迭代，配置界面待交互稿确认后再排期。这个结论比整体结转更具体，下一迭代的容量分配也更准确。
实际判定中常见的误解有三类。一是把重评当成走过场，会上逐项确认后全部结转，实质仍是默认结转。二是把“优先级高”当作唯一标准，忽略可执行性和延期原因，导致高优先级事项反复延期。三是把重评结论记成一句“继续跟进”，没有写明去向和依据，下一迭代规划时无法追溯，重评失去意义。
判定结论的记录应包含四项内容：事项标识、四条标准的逐项判断结果、最终去向、以及责任人和时间。记录粒度到单个事项，不按模块或批次合并。这样在下一迭代规划时，可以直接依据记录分配容量；在迭代回顾时，也能核对当初判断的前提是否发生变化。
常见问题
迭代未完成工作重评和迭代回顾是什么关系？
两者在收尾阶段衔接，但处理对象不同。重评处理本次迭代未完成事项的去向，产出的是继续排期、拆分后继续、降级回需求池或关闭的结论；迭代回顾讨论的是流程、协作和质量层面的改进建议。重评结论可以作为回顾会的输入之一，回顾会上的改进项也可能影响下一轮重评的判断标准，但两者不能互相替代。
如果未完成事项的延期原因暂时无法消除，应该怎么处理？
延期原因未消除时，第四项标准不成立。此时不建议直接排入下一迭代，可以保留在待办中并标注阻塞条件和依赖方，等阻塞解除后再进入排期；如果阻塞短期内无法解除且事项价值已下降，也可以关闭并记录原因。关键是把阻塞状态写清楚，让下一迭代规划时能看到真实约束。
重评结论需要多细？按模块合并记录可以吗？
建议记录粒度到单个事项，不按模块或批次合并。每条记录包含事项标识、四条标准的逐项判断结果、最终去向、责任人和时间。合并记录会丢失单项判断依据，下一迭代规划时难以核对容量，回顾时也无法判断当初的前提是否发生变化。
团队刚开始做重评，有没有简化的起步方式？
可以先从四条标准中挑出最常出问题的两条重点判断，例如可执行性和延期原因，其余两条做简要确认，逐步过渡到逐项对照。起步阶段建议把结论记录模板固定下来，减少收尾会上的讨论成本。等团队熟悉后再完整执行四条标准，避免一开始就因流程过重而流于形式。
重评结论在工具里怎么记录比较合适？
ONES 敏捷研发管理解决方案覆盖需求池管理、迭代规划、迭代开发、迭代进度跟进、迭代回顾等场景，团队可以围绕项目计划、工作项和迭代安排协同工作，及时了解任务状态和待处理事项。重评结论可以依托工作项状态和迭代安排记录与交接；迭代完成并发布后，还可以通过燃尽图、工时日志等报表复盘进度偏差。具体的记录字段和流转规则属于团队管理约定，需要团队在流程中明确。
