迭代未完成工作重评的判定标准是什么

2026年11月4日

迭代结束时，未完成的工作并不天然顺延到下一轮。重评要求逐项重新判断：这项工作对应的用户问题或业务目标是否仍然成立，是否仍属于当前产品目标，现有信息是否足以支撑下一轮排期，再决定保留、拆分、降级还是关闭。判定标准围绕价值、范围、信息三条主线展开，状态与处置作为落地补充。本文说明这套标准的具体依据、适用对象和运转方式。

Table of Contents

要点总览（TL;DR）

重评的判定标准围绕价值、范围、信息三条主线展开：用户问题或业务目标是否仍成立、是否仍属于当前产品目标、描述与验收条件是否足以支撑下一轮排期。
状态标准区分真正未开始、进行中受阻、已完成待验收三种情形，处置标准对应保留、拆分、降级、关闭四类结论，每类结论都应有书面理由。
重评对象是迭代结束时未达到完成定义的工作项；已完成并满足完成定义的工作项不进入重评，产品待办列表的长期排序归需求池管理。
重评与自动结转的关键区别在于逐项判断：自动结转原样顺延，重评的结论可能是拆分、降级或关闭，结论回到待办列表等待重新排序。

重评判定看哪几条标准

重评的核心问题是“这项工作还值不值得继续投入、以什么形态继续”。判定时按价值、范围、信息三条主线逐项核对，再用状态和处置标准把结论固定下来。每条标准都应能找到可观察的依据，避免凭印象决定去留。

标准	判断问题	可观察依据
价值标准	未完成项对应的用户问题或业务目标是否仍然成立	目标用户与场景是否变化、相关业务指标是否仍需要改善、需求提出方是否仍确认要解决该问题
范围标准	是否仍属于当前产品目标与迭代主题	与当前版本目标、迭代主题的对应关系；若已偏离，应退回待办列表等待重新排序
信息标准	描述、验收条件、估算是否足以支撑下一轮排期	需求描述是否完整、验收条件是否明确可验证、剩余工作量是否有估算、依赖是否已记录
状态标准	未完成的具体情形是哪一种	真正未开始、进行中受阻、已完成待验收三种情形对应不同的后续动作
处置标准	应得出哪类结论	保留、拆分、降级、关闭四类结论各有触发条件

状态标准决定重评的起点。真正未开始的工作项，重点判断价值和范围是否仍成立；进行中受阻的工作项，需要先识别阻碍是否可解除、剩余部分能否独立交付；已完成待验收的工作项，问题通常出在验收环节，应推动验收而非重新规划。把三种情形混在一起讨论，容易让“未完成”变成一个笼统标签，掩盖真正需要处理的问题。

处置标准把判断转成明确结论。价值与范围均成立、信息完整、阻碍可解除的，保留并回到待办列表等待重新排序；价值成立但整体过大或部分受阻的，拆出可独立交付的部分，其余退回待办列表；价值仍成立但优先级明显下降、短期内不具备投入条件的，降级处理；价值已不成立、目标已被替代或与其他工作重复的，关闭并记录理由。四类结论都应有书面理由，便于后续复盘时追溯判断依据。

重评的对象边界：哪些工作要重评，哪些不用

重评对象是迭代结束时未达到完成定义的工作项。完成定义是判断“完成”的统一口径，只有对照它才能确定哪些工作真正未完成。已经满足完成定义的工作项不进入重评，即使它在迭代后期才完成，也按已完成处理。

需要区分的是“未完成”与“未验收”。工作项已交付但尚未通过验收，仍属于未达到完成定义，应进入重评，但处理重点在推动验收、补齐验收条件，而非重新评估价值。反过来，工作项在迭代内被主动关闭或合并，也不属于重评对象，它的处置在关闭当时已经完成。

产品待办列表的长期优先级排序归需求池管理，不在重评范围内。重评只回答“本次未完成项接下来怎么办”，不承担对整个待办列表重新排定优先级的职责。跨迭代的路线图调整、版本发布策略变化属于规划层面，与单次迭代结束时的重评分开处理；重评结论可以作为规划调整的输入，但两者不是同一件事。

重评如何运转：从迭代结束到结论落地

重评以迭代结束为起点，通常安排在迭代评审或回顾前后进行。评审关注增量是否可交付，回顾关注过程改进，重评则专门处理未完成项的去向，三者可以衔接在同一时间段内完成，但讨论对象不同。

参与角色按判断内容分工。产品负责人判断价值与范围，确认用户问题是否仍成立、工作项是否仍属于当前产品目标；团队成员判断估算与阻碍，说明剩余工作量、受阻原因以及阻碍能否在下轮解除。两类判断合并后形成处置结论，避免由单一角色同时决定价值和技术可行性。

输入信息包括完成定义、验收条件、阻碍记录和剩余工作量。完成定义用于确认工作项确实未完成，验收条件用于判断信息是否充分，阻碍记录说明进行中受阻的具体原因，剩余工作量支撑拆分与重新估算。缺少这些信息时，重评应先补齐信息，再下结论。

输出结果是每项未完成工作的处置结论与理由。结论去向是回到产品待办列表等待重新排序，而非直接进入下一迭代。这一点决定了重评的实际作用：它把未完成项从“默认顺延”改为“重新进入候选池”，由后续的迭代规划按优先级重新选择。

结论落地需要工作项状态与待办列表的配合。在 ONES 的敏捷研发管理场景中，需求池管理、迭代规划、迭代开发与迭代回顾构成连续环节，产品负责人可依据优先级把待办列表中的需求规划到对应迭代，团队在迭代中通过敏捷看板管理任务状态。重评得出的拆分结论可以借助子工作项落到具体任务，退回待办列表的工作项则等待下一轮规划重新选择。这样，重评的判断结果能对应到工作项的实际状态，而不是停留在会议记录里。

重评与自动结转、需求池排序的区别

重评容易被与几个相邻做法混为一谈，差异主要在判断动作和结论去向。

概念	处理对象	是否逐项判断	典型结论
自动结转	本次迭代未完成项	否，原样进入下一迭代	工作项直接顺延，价值与范围未经复核
重评	本次迭代未完成项	是，按价值、范围、信息逐项判断	保留、拆分、降级或关闭，回到待办列表
需求池排序	全部待办项	按长期优先级统一排序	确定各项在待办列表中的相对位置
迭代评审	本次迭代增量	关注增量是否可交付	确认可交付内容，收集反馈

自动结转的问题在于跳过了判断环节。未完成项原样进入下一迭代，可能把已经失去价值的工作继续占用迭代容量，也可能让受阻项在没有解除阻碍的情况下再次拖延。重评的价值正在于逐项确认后再决定去向，结论可以是关闭或拆分，而不只是顺延。

需求池排序面向全部待办项的长期优先级管理，重评只处理本次未完成项，两者在对象和时间范围上都不同。重评结束后，结论回到待办列表，后续排序仍按需求池管理的规则进行。迭代评审与重评的区别则在关注点：评审看增量是否可交付，重评看未完成项如何处置，二者可以同场进行，但输出不同。

一个具体例子与常见误解

假设某迭代中一个需求开发到一半，因外部接口依赖未就绪而受阻。重评时逐条对照标准：价值标准上，该需求对应的用户问题仍然成立，提出方确认仍需要解决；范围标准上，它仍属于当前版本目标；信息标准上，验收条件明确，但剩余部分依赖外部接口，短期内无法整体交付；状态标准上，属于进行中受阻。据此得出的结论是拆分：把不依赖外部接口、可独立交付的部分拆出，安排进后续排期；其余部分退回待办列表，并标注依赖与解除条件。这个例子说明，价值成立并不等于整体保留，拆分同样是重评的合理结论。

实际执行中，有三类误解需要纠正。

误解一：未完成就默认顺延到下一迭代。顺延跳过了价值与范围判断，重评要求先判断再决定去向，结论可能是关闭或拆分。
误解二：重评等于重新估算工时。估算是信息标准的一部分，用于支撑拆分和排期，重评的核心是判断工作是否还值得做、以什么范围做。
误解三：所有未完成项都必须保留。价值已不成立、目标被替代或与其他工作重复的工作项应当关闭，保留全部未完成项会让待办列表持续膨胀，稀释真正重要的优先级。

把这三条误解排除后，重评的判定标准可以归纳为一句话：以完成定义为前提确定对象，以价值、范围、信息为判断主线，以状态区分情形，以处置结论落到待办列表。标准本身不复杂，难点在于每项结论都要有可追溯的理由。

常见问题

迭代结束时工作项已交付但还没通过验收，应该重评还是直接顺延？

这类工作项仍属于未达到完成定义，应进入重评，但处理重点与真正未开始或进行中受阻的工作项不同。判断时先确认验收条件是否明确、验收方是否已安排，问题通常出在验收环节，应推动验收完成，而不是重新评估价值或重新规划范围。如果验收条件本身缺失或不可验证，则先补齐验收条件，再决定是否保留。

重评得出的结论需要记录到什么程度，才够后续复盘使用？

每项未完成工作至少记录三样信息：处置结论（保留、拆分、降级或关闭）、判断理由（对应哪条标准不满足或仍成立）、后续动作（拆分出的部分安排到哪、退回待办列表的依赖条件是什么）。理由要能对应到可观察依据，例如目标用户变化、业务指标不再需要改善、依赖未解除等。记录过简会让下一轮规划无法判断该项为何被保留或关闭，复盘时也难以追溯。