迭代未完成工作重评检查清单

2026年11月4日

迭代结束时，未完成工作怎么处理，直接影响下一迭代的计划质量。重评检查清单的作用，是把“逐项判断继续、拆分、改期还是关闭”变成可核对的步骤：谁在什么时点评、评前准备哪些数据、每项看什么、记录哪些字段、什么情况不能放行。本文给出一份可直接使用的检查表，适用于迭代负责人、产品负责人与开发测试代表，在迭代评审前后、下一迭代计划前使用。

Table of Contents

要点总览（TL;DR）

重评的使用对象是迭代负责人、产品负责人与开发测试代表，时点在迭代评审前后、下一迭代计划前，前置输入包括工作项清单、完成状态与剩余工作量记录。
准备阶段先核对范围覆盖、状态更新、剩余工作量、阻塞依赖、参与人与遗留项，数据不齐时推迟会议或缩小范围。
逐项判断按原因归类、剩余工作量重估、优先级确认、依赖复核、结论选择、新归属与负责人六步走，结论在继续、拆分、改期、关闭、转需求池中选一。
重评记录至少包含工作项标识、原计划迭代、实际进展、未完成原因、剩余工作量、重评结论、新归属迭代、负责人、评审人与重评日期。
存在未给出结论、剩余工作量未重估、归属或负责人缺失等情况时，阻断迭代关闭与下一迭代启动，解除后再放行。

谁在什么时点使用这份重评清单

这份清单服务于迭代收尾阶段的一次专门判断，而不是结项后的补录。使用对象和职责如下表，团队可按规模合并角色，但判断与确认的职责需要有人承担。

角色	在重评中的职责	主要动作
迭代负责人	组织重评、维护清单完整性	汇总未完成项，主持逐项判断，记录结论
产品负责人	确认优先级与业务价值	判断是否继续、改期、关闭或转需求池
开发代表	提供技术进展与剩余工作量	重新估算剩余工作，说明阻塞与依赖
测试代表	说明验证状态与质量风险	标注未验证项、缺陷关联与回归影响

使用时点有两个：一是迭代结束的评审会上，对全部未完成项逐项给出结论；二是下一迭代计划开始前，核对结论是否已落到新归属迭代和负责人。两个时点之间不宜留空档，否则未完成项容易在计划会上被默认带入下一迭代。

重评开始前需要准备三类前置输入：本迭代全部工作项清单及其完成状态、每项未完成工作的剩余工作量记录、已识别的阻塞与外部依赖。缺少任何一类，重评就会退化为凭印象讨论。

需要强调的是，未完成工作必须逐项判断。默认结转到下一迭代看似省事，但会把估算偏差、优先级变化和阻塞问题一起带入新周期，下一迭代的计划承诺随之失真。清单的每一项检查，都是为了让“继续、拆分、改期、关闭”成为有依据的决定。

重评前的准备检查项

准备阶段的目标是让重评基于完整、可核对的工作项清单。以下检查项在重评会议开始前完成，由迭代负责人逐项确认。

检查项	通过标准	证据	负责人
工作项范围覆盖	本迭代全部未完成项均已列入重评清单，数量与迭代工作项列表一致	迭代工作项列表与重评清单对照	迭代负责人
完成状态更新	每项状态为最新，已完成、部分完成、未开始区分清楚	工作项状态更新记录	开发代表
剩余工作量记录	每项未完成工作有剩余工作量估计，单位与团队估算口径一致	工作项中的剩余工作量字段或估算记录	开发代表
阻塞与依赖标注	存在阻塞、外部等待、跨团队依赖的项已单独标注并写明等待对象	工作项备注或阻塞标记	开发代表、测试代表
参与人确定	产品负责人、开发与测试代表已确认参加，时间与议程已通知	会议邀请或议程记录	迭代负责人
遗留项纳入	上一迭代结转至本迭代仍未完成的项已纳入本次范围，并注明原始来源	遗留项清单与本次清单对照	迭代负责人

准备检查不通过时，重评会议应推迟或缩小范围，先补齐数据。特别是剩余工作量缺失的项，现场估算容易受讨论氛围影响，建议由负责人在会前完成初估，会上只做确认和调整。

逐项重评的判断检查项

逐项判断是重评的核心环节。对每一项未完成工作，按以下顺序核对，形成一条明确结论。

判断要点	核对内容	判断通过的条件
未完成原因归类	从需求变更、估算偏差、阻塞依赖、资源不足、优先级调整中选择主要原因，可补充说明	原因已写明且与工作项记录一致，不停留在“时间不够”这类笼统描述
剩余工作量重估	基于当前进展重新估算剩余工作，而非沿用原估算	有新的剩余工作量数值或范围，并由承担人确认
优先级与业务价值确认	产品负责人确认该项在当前业务条件下的优先级是否变化	优先级有明确结论，变化时说明依据
依赖与风险复核	阻塞是否已解除、外部等待是否有时间预期、拆分后是否产生新的依赖	依赖状态和风险已记录，未解除的写明跟进人
结论选择	在继续、拆分、改期、关闭、转需求池中选定一项	结论唯一且与原因、剩余工作量、优先级相匹配
新归属与负责人	继续或拆分的项明确进入哪个迭代；改期的项写明目标时间；关闭和转需求池的项写明后续处理方式	新归属迭代与负责人均已填写，无空缺

结论选项的使用条件需要说清楚：继续，指工作内容不变、剩余工作量明确、下一迭代有容量承接；拆分，指原工作项过大或部分内容已可独立交付，拆出的子项各自有估算和归属；改期，指当前优先级下降或依赖未就绪，需明确改到哪个时间窗口；关闭，指需求已失效、被其他工作覆盖或确认不再需要；转需求池，指工作仍有价值但暂不排入近期迭代，交回需求池统一管理。

拆分和转需求池容易被当成“先放一放”的出口。判断时要确认拆分后的子项仍有人负责、转需求池的项有重新进入评估的触发条件，否则重评只是把问题挪了位置。

重评记录应包含的字段

重评结论要能被人复核，记录字段必须完整。下表列出必填字段及填写要求，可在工作项系统或评审记录表中落地。

字段	是否必填	填写说明
工作项标识	必填	原工作项编号或名称，保证可回溯到原始条目
原计划迭代	必填	该项原本承诺的迭代，用于统计结转情况
实际进展	必填	已完成的部分、当前所处环节，用事实描述
未完成原因	必填	按归类填写主要原因，可附简要说明
剩余工作量	必填	重估后的数值或范围，注明估算口径
重评结论	必填	继续、拆分、改期、关闭、转需求池之一
新归属迭代	条件必填	继续、拆分、改期时必填；关闭和转需求池填写后续处理去向
负责人	必填	承接后续工作的人，关闭项填写确认关闭的人
评审人	必填	对结论负责的评审角色，通常为产品负责人或迭代负责人
重评日期	必填	结论形成日期，与评审会议日期对应
结论说明	条件必填	结论与常规处理不同、或涉及优先级调整时填写理由

记录字段的价值在于可追溯：后续有人问“这项为什么没做完、为什么改期”，能直接从记录中找到原因、重估结果和评审人。字段缺失的记录，在下一迭代计划会上往往需要重新讨论一遍。

在工具层面，这类记录通常依托迭代工作项的状态流转与评审记录完成。以ONES为例，工作项可以在迭代视图中更新状态、剩余工作量和归属迭代，评审结论可作为工作项字段或评审记录留存，使重评结果与原始工作项保持关联，便于在下一迭代计划时直接核对。具体字段配置需按团队实际流程设置。

通过标准与证据留存

重评是否完成，不能以“会开过了”为准，而要按下列标准逐条判断。每条标准都对应可留存的证据。

通过标准	判断方法	留存证据
每项未完成工作均有明确结论	重评清单中结论字段无空白，结论属于五个选项之一	重评清单或工作项更新记录
结论与新归属、负责人一致	继续、拆分、改期的项均有新归属迭代和负责人；关闭、转需求池的项有后续处理说明	工作项归属变更记录
记录字段完整	必填字段全部填写，条件必填字段在对应结论下无缺失	评审记录表
可追溯到原工作项	任取一条记录，能通过工作项标识找到原始条目及其历史状态	工作项历史记录
评审人确认	每条结论有评审人确认，会议结论与记录一致	评审记录中的确认信息或会议纪要

证据形式以系统记录为主、会议纪要为辅。工作项的状态变更、剩余工作量更新、归属迭代调整构成过程证据；评审记录和会议纪要说明判断依据与参与人。两者相互对应，才能支撑后续复盘和审计式核对。

如果团队使用ONES管理迭代，重评后的状态更新、归属调整和评审记录会自然沉淀在工作项上，下一迭代计划时可直接按原迭代筛选查看结转项及其结论，减少重复核对。

阻断项与完成条件

以下情况出现时，应阻断迭代关闭或下一迭代启动，直到对应条件解除。阻断项由迭代负责人检查，解除责任落到具体角色。

阻断项	解除条件	责任人
存在未给出重评结论的未完成项	逐项补评并填写结论，评审人确认	迭代负责人
剩余工作量未重新估算	由承担人完成重估并记录数值或范围	开发代表
新归属迭代或负责人缺失	补齐归属与负责人，或改为关闭、转需求池并写明处理方式	产品负责人、迭代负责人
阻塞项未标注跟进人	写明阻塞对象、跟进人和预期解除时间	开发代表
评审记录与会议结论不一致	核对并修正记录，由评审人重新确认	迭代负责人

迭代关闭的完成条件可以归纳为三条：全部未完成项有结论，结论已落到归属与负责人，记录完整并经评审人确认。下一迭代启动的附加条件是：新归属到本迭代的结转项已计入容量评估，避免计划承诺超出团队实际负荷。

阻断不是惩罚机制，而是防止问题被静默带入下一周期。解除阻断的过程本身会暴露估算、依赖和优先级管理中的具体问题，这些信息正是迭代回顾的有效输入。

常见问题

迭代未完成工作重评和迭代回顾有什么区别，能否合并进行？

两者可以安排在同一场会议，但输出不同。回顾关注过程与改进措施，重评关注每项未完成工作的去向。合并时建议先做重评，把结论逐项落到记录上，再进入回顾讨论；如果时间紧张，重评可以单独开短会，避免结论被回顾讨论冲淡。无论是否合并，重评记录字段都要完整填写，评审人确认后才能作为迭代关闭的依据。

剩余工作量在重评会上现场估算可以吗？

可以，但建议由承担人在会前完成初估，会上只做确认和调整。现场从零开始估算，容易受讨论氛围和在场人员影响，数值偏差较大。准备检查中把剩余工作量列为会前必查项，就是为了让重评讨论集中在判断上，而不是重新做估算。确实无法会前估算的项，应在记录中注明估算时点和参与人。

拆分和转需求池的项，怎样避免变成无人跟进？

关键在重评记录里写清承接关系。拆分的项要为每个子项填写负责人和新归属迭代，子项各自有剩余工作量；转需求池的项要写明重新进入评估的触发条件，例如业务方再次提出、依赖解除或版本窗口确定。记录中没有负责人或触发条件的项，应视为阻断项，补齐后再放行。

团队规模较小、角色合并时，这份清单怎么用？

角色可以合并，职责不能省略。例如迭代负责人同时承担产品负责人的优先级确认职责时，仍要在记录中分别体现判断依据和确认动作，避免同一人既提结论又免于核对。准备检查、逐项判断、记录字段和阻断项四部分保持不变，只是执行人减少。规模小的团队可以把重评会议压缩到半小时，按清单顺序逐项过，重点保证每项都有结论和归属。