迭代回顾记录要能支撑下一次迭代的调整，关键在于每个结论都有事实依据，每个改进都落到负责人和期限。本文提供一份虚构的两周迭代回顾记录示例，按“基本信息—目标与完成情况—数据与事实—做得好的—待改进的—行动项—未完成工作去向”的顺序完整填写，并逐项解释填写依据，便于团队对照使用。
要点总览（TL;DR）
- 迭代回顾记录按“基本信息—目标与完成情况—数据与事实—做得好的—待改进的—行动项—未完成工作去向”填写，每个结论都要有可核对的事实支撑。
- 目标栏写可判断达成与否的结果，数据栏优先使用迭代过程中已有的记录，行动项写清动作、负责人、期限和完成标志。
- 未完成工作逐项重新评估后再决定去向，可以是带入下个迭代、退回需求池、合并处理或关闭，每种去向写明理由。
- 行动项登记为可分配、有期限的工作项并与迭代任务同处跟踪，回顾结论才能在下个迭代被检查。
- 团队规模、迭代长度、远程协作和外部依赖不同时，字段取舍与记录重点需要相应调整，避免机械套用。
这份回顾记录示例要解决什么问题
本文的示例以一支虚构的八人产品研发团队为背景，迭代周期为两周，记录内容从头到尾填写完整。示例中出现的团队名称、人员姓名、需求条目和数据均为演示情景，用于说明记录的写法，不代表任何真实客户案例或实测结果。读者可以把这份记录当作模板参照，替换成自己团队的真实信息。
这份记录要回答三个问题：这个迭代承诺了什么、实际交付了什么、下一个迭代要改变什么。因此记录覆盖迭代目标、完成情况、数据事实、问题与行动项，最后交代未完成工作的去向。记录服务于下一次迭代的调整，填写时聚焦在流程、协作和计划安排上，避免把回顾写成个人绩效评价或追责材料。
拿到这份示例后，读者可以对照检查自己的回顾记录是否缺项：目标是否写成了可判断的结果、数据是否可核对、行动项是否有负责人和期限、未完成工作是否逐项有了结论。这四项是记录能否被使用的分界线。
完整示例：两周迭代的回顾记录全文
以下为示例记录全文，团队名称“晨星小组”、人员姓名和所有数据均为虚构。
迭代基本信息
| 字段 | 填写内容 |
|---|---|
| 迭代名称 | 晨星小组 2024 年第 12 迭代 |
| 迭代周期 | 3 月 4 日至 3 月 15 日，共 10 个工作日 |
| 迭代目标 | 完成订单导出功能上线，并将订单列表页首屏加载时间从 2.8 秒降到 1.5 秒以内 |
| 参与角色 | 产品负责人 1 人、开发 4 人、测试 1 人、设计 1 人、团队负责人 1 人 |
| 回顾参与人 | 上述 8 人全部参加，会议时长 60 分钟 |
目标达成与未达成的事实描述
目标一“订单导出功能上线”：已达成。导出功能于 3 月 13 日进入预发布环境，3 月 14 日完成验收，支持按时间范围和订单状态筛选导出，单次导出上限 5 万条。
目标二“首屏加载时间降到 1.5 秒以内”：部分达成。列表页首屏加载时间从 2.8 秒降至 1.9 秒，未达到目标值。已定位主要耗时在历史订单的关联查询，优化方案已评审但未在本迭代实施。
数据与事实
| 指标 | 数值 | 说明 |
|---|---|---|
| 计划工作项数 | 18 项 | 迭代计划会确认的范围 |
| 完成工作项数 | 15 项 | 达到验收标准并进入预发布环境 |
| 范围变更次数 | 2 次 | 一次为新增导出格式需求，一次为移除旧版报表迁移 |
| 中途插入的紧急需求 | 1 项 | 线上支付回调异常修复，占用约 1.5 人天 |
| 缺陷情况 | 本迭代发现 9 个，关闭 8 个 | 剩余 1 个为低优先级样式问题，已登记 |
做得好的
- 导出功能在开发中期就安排了测试介入，验收阶段只发现 2 个问题，返工量明显低于以往同类功能。
- 每日站会控制在 10 分钟内，阻塞问题当天登记并指定跟进人，本迭代没有出现超过一天的隐性阻塞。
- 范围变更均在变更当天由产品负责人和团队负责人共同确认，并同步调整了计划，没有出现变更后无人知晓的情况。
待改进的
- 性能优化类工作缺少提前的技术验证，方案在迭代后期才评审，导致实施时间不足。
- 紧急需求插入时没有同步评估对原计划的影响，第 12 迭代的计划完成率因此低于预期。
- 关联查询的历史数据量在计划阶段没有核实，估算依据偏乐观。
行动项
| 行动项 | 负责人 | 期限 | 完成标志 |
|---|---|---|---|
| 对历史订单关联查询做技术验证，输出优化方案与工作量估算 | 开发 A | 3 月 20 日 | 方案文档在迭代计划会前完成评审 |
| 制定紧急需求插入的评估清单，包含对原计划的影响说明 | 产品负责人 | 3 月 22 日 | 清单在下次迭代计划会试用 |
| 性能类需求在计划阶段补充数据量核实步骤 | 测试 B | 3 月 22 日 | 写入团队计划检查项 |
未完成工作的逐项去向
| 未完成工作项 | 重新评估结论 | 去向 |
|---|---|---|
| 首屏加载性能优化实施 | 方案未验证，直接带入下个迭代会挤占已承诺范围 | 先完成技术验证，验证通过后放入下个迭代计划 |
| 旧版报表迁移（已从范围移除） | 业务方确认本季度不再需要 | 退回需求池，暂不排期 |
| 低优先级样式缺陷 | 影响范围小，可与其他样式调整合并处理 | 并入下个迭代的样式优化条目 |
逐项解释：每个字段为什么这样填
示例中的每个字段承担不同的判断任务，填写方式直接影响记录能否被下一次迭代使用。以下拆解关键字段的填写依据。
目标栏写结果，不写任务清单
示例中的目标写成“首屏加载时间降到 1.5 秒以内”，这是一个可以判断达成与否的结果；如果写成“完成性能优化相关工作”，回顾时就无法说清做到什么程度。目标栏的检验方法是：迭代结束时，团队能否用“达成、部分达成、未达成”加一句事实说明来回答。任务清单适合放在计划范围里，目标栏保留一到两个可判断的结果即可。
数据栏用可核对的事实支撑判断
示例中的数据都来自迭代过程中的记录：计划项数来自计划会确认的范围，完成项数按验收标准统计，范围变更次数按变更记录计数。数据栏的作用是让“完成得怎么样”这个判断有据可查，因此优先选择团队日常已经在记录的指标，避免为回顾临时估算。数据不必求多，计划与完成对比、范围变更、缺陷情况这三类通常足以支撑讨论。示例中的数值仅用于演示格式，团队应填写自己的真实统计。
行动项写清动作、负责人、期限
对比两种写法：“加强性能意识”无法追踪；“对历史订单关联查询做技术验证，开发 A 负责，3 月 20 日前完成方案评审”则可以在下个迭代检查。行动项还应写明完成标志，让“做完了”有统一判断。示例中三个行动项分别对应三条待改进内容，保持一一对应，避免改进讨论结束后无人认领。
未完成工作写重新评估结论，不直接顺延
示例中的性能优化工作没有默认带入下个迭代，而是先判断方案是否验证、带入后是否挤占已承诺范围，再决定去向。直接顺延的风险在于：未完成项不断累积，下个迭代的计划从一开始就超载。逐项重新评估后，去向可以是带入下个迭代、退回需求池、合并处理或关闭，每种去向都应写明理由。
从这份示例可以迁移的写法
示例的具体内容属于虚构团队，但记录的组织方式可以迁移到不同团队和迭代周期。以下规律在多数回顾场景中适用。
- 先事实后判断。先写目标达成情况、数据和工作项状态，再写做得好的与待改进的。顺序反过来，讨论容易变成印象之争。
- 控制行动项数量。一次回顾产出三到五条行动项，团队有能力在下个迭代内完成并检查；条目过多时，优先保留与下个迭代计划直接相关的几条。
- 记录长度随迭代复杂度调整。范围稳定、变更少的迭代，数据和改进部分可以精简；出现多次范围变更、紧急插入或跨团队依赖时，相应补充事实描述和原因分析。
- 与下一迭代计划衔接。回顾结论中的行动项和未完成工作去向，应在下个迭代计划会上作为输入使用，而不是停留在回顾文档里。
- 行动项进入工作项跟踪。回顾记录中的行动项如果只写在文档里，容易在下一个迭代被遗忘。把行动项登记为可分配、有期限的工作项，与迭代任务放在同一处跟踪，下个回顾会直接查看完成状态，记录与执行就形成了闭环。ONES 的工作项支持指定负责人和截止时间，行动项可以作为独立工作项纳入下个迭代跟踪；未完成工作的去向也可以在调整迭代范围时同步更新状态。
适用边界：哪些情况需要调整示例
示例基于八人团队、两周周期、单一产品线的设定。团队情况不同时，字段取舍和记录重点需要相应调整，机械套用会带来额外负担或遗漏关键信息。
团队规模与迭代长度不同
人数较少、周期为一周的团队，可以合并“做得好的”和“待改进的”为一节，数据栏保留计划与完成对比即可。人数较多或分为多个子团队时，建议按子团队分别记录目标达成情况，再汇总为一份迭代记录，避免一份记录里混入无法归属的结论。
远程或跨团队协作
远程协作时，补充回顾会议的参与方式、异步收集意见的时间窗口，以及未能参会人员的意见来源。跨团队协作的迭代，在基本信息中注明各团队的对接人，在待改进部分区分团队内部问题与协作接口问题，便于把行动项分配给正确的责任方。
涉及外部依赖
当迭代目标依赖外部供应商、其他部门或第三方接口时，记录中应写明依赖事项、约定时间和实际到位情况。外部依赖导致的延期，在未完成工作去向中单独说明，并明确下一步的跟进人和确认时间，避免把外部原因笼统写成“客观因素”。
未完成工作重新评估的边界
逐项重新评估适用于大多数未完成工作，尤其是方案未验证、需求优先级变化或工作量估算偏差的条目。对于已经投入大量工作、仅剩收尾的条目，重新评估的结论可以是“优先完成收尾”，但仍需写明理由和预计工作量，而不是默认顺延。评估结论应记录在案，供下个迭代计划会直接引用。
常见问题
迭代回顾记录和迭代评审记录有什么区别，需要分开写吗？
两者关注的对象不同。评审记录面向交付物，说明这个迭代做出了什么、验收结果如何；回顾记录面向团队的工作方式，说明哪些做法有效、哪些环节需要调整。示例中的“目标达成与未达成的事实描述”更接近评审内容，回顾记录可以引用评审结论，但不必重复验收细节。
如果团队会议时间有限，可以合并为一次会议，记录仍建议分成两部分：交付结果部分供相关方查阅，改进与行动项部分供团队内部跟踪。分开写的好处是行动项的负责人和期限更清晰，不会被交付细节淹没。
回顾会上大家不愿意说问题，记录怎么写才不流于形式？
先从事实入手，把目标达成情况、数据和工作项状态摆出来，再讨论原因，讨论就不容易变成互相评价。示例中“待改进的”三条都指向具体环节，例如性能优化缺少提前的技术验证、紧急需求插入时没有评估对原计划的影响，这类描述指向流程，参与者更容易开口。
另一个做法是控制行动项数量，一次回顾只保留三到五条团队确实能完成的改进，并在下个迭代检查完成状态。改进被真正执行，团队才会愿意在下次回顾中继续提出问题。
一个迭代里插入的紧急需求，回顾记录中应该怎么体现？
建议在数据栏单独记录紧急需求的数量和占用的人天，并在待改进部分说明插入时是否评估了对原计划的影响。示例中记录了一次线上支付回调异常修复，占用约 1.5 人天，同时把“插入时没有同步评估影响”列为待改进项。
如果紧急需求频繁出现，可以在行动项中安排制定插入评估清单，明确谁有权确认插入、插入后如何调整原计划。这样记录既保留了事实，也指向可执行的改进，而不是停留在抱怨需求方。
未完成工作全部重新评估，会不会让回顾会议时间过长？
可以在会前完成大部分评估。会前由每项未完成工作的负责人给出初步结论和理由，会上只讨论有分歧或涉及范围调整的条目。示例中的三项未完成工作分别给出了不同去向，评估依据是方案是否验证、业务方是否仍需要、能否合并处理，判断标准相对明确，逐项过一遍的时间可控。
对于仅剩收尾的条目，评估结论可以是优先完成收尾，但仍需写明理由和预计工作量。评估结论记录在案，下个迭代计划会直接引用，避免会上重复讨论。
回顾记录需要长期保存吗，保存下来有什么用？
建议保留，至少保留最近几个迭代的记录。连续几份记录放在一起，可以看出行动项是否被完成、同类问题是否反复出现。例如性能类工作连续两个迭代都因验证不足而延期，就说明改进措施没有生效，需要调整做法而不是再写一条相同的行动项。
保存方式上，把回顾记录与对应迭代放在同一处管理，行动项作为工作项跟踪，查阅时可以直接对照记录与完成状态。记录内容涉及团队内部讨论，访问范围可按团队约定设置。
