迭代执行跟踪要能回答三个问题：迭代承诺了什么、当前实际做到哪一步、偏差如何处理。支撑回答的依据包括经确认的迭代目标与验收口径、按容量校准的Sprint Backlog、任务状态与剩余工作量、阻塞与变更记录、评审回顾结论等。这些依据按同一口径持续更新，跟踪才有判断力。ONES可承载迭代目标、工作项状态与阻塞记录，让依据随执行同步沉淀。
要点总览（TL;DR）
- 迭代执行跟踪需要六类依据：迭代目标与验收口径、Sprint Backlog与任务拆分、容量与可用工时基线、状态与剩余工作量记录、阻塞风险与变更记录、评审回顾与未完成项结论。
- 前三类依据在规划会上形成基线，后三类在执行过程中持续产生；每日跟进更新状态与剩余量，范围调整先登记再确认，评审回顾固化结论。
- 依据由产品负责人、迭代负责人、开发成员分别提供，管理者使用依据做判断；角色可以合并，依据的来源和确认动作不宜省略。
- 未完成工作需逐项重新评估，明确继续、拆分重排或取消，并记录原因，不默认自动结转。
- 用完整性、时效性、口径一致性、变更登记、阻塞跟进和未完成项处理逐项检查，判断依据是否足以支撑跟踪。
跟踪前先定依据：迭代执行跟踪的六类依据
跟踪不是每天问一句“进度怎么样”，而是拿一组事先约定的记录做比对。依据不足时，跟踪会退化成口头汇报；依据齐全时，团队和管理者都能用同一份事实讨论偏差。下面六类依据分别回答一个具体的跟踪问题，缺哪一类，判断就会在对应环节失去支撑。
| 依据类别 | 具体内容 | 回答的跟踪问题 |
|---|---|---|
| 迭代目标与验收口径 | 本迭代要达成的目标、对应验收标准、优先级顺序 | 迭代承诺了什么，什么算做完 |
| Sprint Backlog与任务拆分 | 承诺范围内的工作项、任务拆分、依赖关系、估算 | 承诺由哪些工作构成，颗粒度是否可跟踪 |
| 容量与可用工时基线 | 团队成员可用天数、请假与占用、单位时间产能参考 | 承诺量与团队实际可投入是否匹配 |
| 状态与剩余工作量记录 | 工作项当前状态、剩余工时或剩余工作量、完成时间 | 当前实际做到哪一步，离完成还有多远 |
| 阻塞、风险与变更记录 | 阻塞事项、风险描述与应对、范围调整的申请与确认 | 偏差从哪来，是否已登记并有人处理 |
| 评审回顾与未完成项结论 | 迭代评审结果、回顾改进项、未完成项的重新评估结论 | 结果是否被确认，遗留工作如何处理 |
六类依据中，前三类在迭代开始时形成基线，后三类在执行过程中持续产生。基线的价值在于提供比较对象：没有经确认的目标和容量，状态记录只能说明“在做什么”，无法说明“是否按承诺推进”。阻塞与变更记录则把偏差从个人记忆变成团队可查的事实，避免跟踪会上反复追溯“什么时候改的、谁同意的”。
需要强调的是，剩余工作量记录应与任务状态配套使用。只有状态没有剩余量，难以判断接近完成还是刚起步；只有剩余量没有状态，难以判断工作是否真正流转。两者结合，才能支撑“按当前速度能否在迭代结束前完成”这类判断。
从规划到每日跟进：依据怎么产生和更新
依据不是跟踪会前临时收集的材料，而是在迭代流程各节点自然产生的记录。每个节点有明确的输入、动作和输出，责任人按分工完成更新，跟踪时直接取用即可。
规划会：形成目标与Backlog基线
输入是产品负责人整理好的高优先级需求与验收口径，动作是团队确认本迭代目标、拆分任务、按容量校准承诺量，输出是经评审确认的迭代目标、Sprint Backlog和容量基线。完成标志是团队对“做什么、做到什么程度、大致怎么拆”达成一致，且承诺量与可用容量经过比对。这一步的产出是后续所有跟踪判断的参照系。
每日跟进：更新状态与剩余量
开发成员在每天跟进前更新自己负责工作项的状态和剩余工作量，站会上围绕“昨天完成什么、今天计划什么、有什么阻塞”同步。迭代负责人核对更新是否与实际一致，把新出现的阻塞登记到阻塞清单并指定跟进人。更新频率以每日一次为常见做法，工作项发生实质变化时应即时更新，避免积压到站会集中补记。
范围调整：先登记再确认
迭代中途出现新增需求或范围缩减时，由提出方说明原因和影响，产品负责人评估优先级，迭代负责人记录调整内容、调整前后承诺量对比和确认结论。调整记录应包含时间、涉及工作项、增减的工作量以及是否影响迭代目标。未经登记的调整会让跟踪失去基准，因此登记动作本身应作为调整生效的前提。
评审与回顾：固化结论
迭代结束时的评审确认哪些工作项满足验收口径，回顾总结过程问题与改进项。对未完成的工作项，团队逐项重新评估：是继续留在下个迭代、拆小后重排，还是取消。重新评估的结论连同原因一并记录，作为下一轮规划和本次跟踪收尾的依据。
| 节点 | 动作 | 输出依据 | 主要责任人 |
|---|---|---|---|
| 规划会 | 确认目标、拆分任务、校准容量 | 迭代目标、Sprint Backlog、容量基线 | 产品负责人、迭代负责人、团队 |
| 每日跟进 | 更新状态与剩余量、登记阻塞 | 状态记录、剩余工作量、阻塞清单 | 开发成员、迭代负责人 |
| 范围调整时 | 说明影响、评估优先级、记录确认 | 变更记录 | 提出方、产品负责人、迭代负责人 |
| 评审与回顾 | 确认结果、评估未完成项、记录改进 | 评审结论、回顾改进项、未完成项结论 | 产品负责人、迭代负责人、团队 |
角色分工：谁提供依据、谁使用依据
跟踪依据由多个角色共同供给，任何一方缺位都会造成依据断档。分工的关键是让每类依据有明确的提供者，同时限定使用者的判断边界，避免跟踪变成单人汇报或越权干预。
| 角色 | 提供的依据 | 交付物 | 使用边界 |
|---|---|---|---|
| 产品负责人 | 迭代目标、验收口径、优先级、范围调整确认 | 目标说明、验收标准、变更确认记录 | 决定做什么和优先级，不替团队分配具体任务 |
| 迭代负责人（Scrum Master） | 容量基线、过程记录规范、阻塞清单、跟踪节奏 | 容量表、阻塞清单、跟进记录、评审回顾纪要 | 维护过程依据的完整与时效，不代替成员更新状态 |
| 开发成员 | 任务状态、剩余工作量、技术阻塞、完成说明 | 更新后的工作项、阻塞上报 | 对自己负责的工作项如实更新，不虚报完成度 |
| 管理者 | —（使用依据） | 基于依据的判断与资源协调 | 依据判断进度与风险、协调资源，不绕过团队直接改状态 |
这张表的核心是“提供者负责准确，使用者负责判断”。产品负责人提供的目标和优先级是跟踪的起点，若目标模糊，后续状态记录再完整也无法判断是否达成。迭代负责人维护的是过程依据的秩序，包括更新是否及时、阻塞是否有人跟进、变更是否登记。开发成员是状态与剩余量的第一来源，其更新质量直接决定跟踪的可信度。管理者使用依据做资源和风险判断时，应回到同一份记录讨论，避免另建一套口径。
当团队规模较小、角色由一人兼任时，仍建议在记录中区分“目标确认”和“过程维护”两类动作，防止目标随执行随意漂移。角色可以合并，依据的来源和确认动作不宜省略。
一个迭代的跟踪依据示例
以下为演示情景，用于说明依据如何串起来支撑一次跟踪判断，不代表真实项目数据。
某团队进入一个两周迭代，规划会确认迭代目标为“完成订单查询接口改造并上线灰度”，验收口径包括接口响应时间达标和灰度覆盖指定比例用户。团队六人，扣除请假和运维值班后可用容量约五十人天，Sprint Backlog拆出十二个工作项，合计估算四十八人天，留有少量缓冲。容量基线、目标与Backlog在规划会后即固定为跟踪基准。
迭代进行到第六天，业务方提出增加一个导出功能。产品负责人评估后认为该功能不阻塞本迭代目标，决定放入下个迭代候选，迭代负责人登记了这次范围讨论：提出时间、评估结论、未纳入本迭代的原因。由于没有实际增减本迭代工作量，承诺量保持不变，但记录留存，避免后续误认为被遗漏。
第十天跟进时，两个工作项因外部接口联调延迟处于阻塞状态，剩余工作量合计八人天，按当前速度存在无法全部完成的可能。迭代负责人将阻塞登记并指定跟进人，管理者据此协调外部接口方。迭代结束时，目标相关工作项全部满足验收口径，一个非目标相关的优化项未完成。团队在评审后对该未完成项重新评估：拆分为两个更小工作项，其中一个放入下个迭代，另一个因优先级下降取消，结论和原因写入记录。
这次跟踪的判断链条是：目标与容量给出承诺基线，状态与剩余量显示偏差，阻塞记录解释偏差来源，变更记录澄清范围讨论，未完成项结论完成收尾。每一环都有对应依据，跟踪会上的讨论因此集中在“如何处理阻塞”而非“到底做了什么”。
完成检查：跟踪依据是否够用
判断依据是否足以支撑跟踪，可以按下面清单逐项核对。每项给出通过标准，未通过时对应补齐动作，避免检查停留在“感觉差不多”。
| 检查项 | 通过标准 | 未通过时的补齐动作 |
|---|---|---|
| 目标与验收口径 | 迭代目标有书面确认，每个目标对应可核验的验收标准 | 由产品负责人补充验收标准并组织确认 |
| Backlog与容量匹配 | 承诺工作量与可用容量经过比对，差异有说明 | 重新核对容量表，补充差异原因 |
| 状态与剩余量时效 | 工作项状态和剩余工作量在最近一个跟进周期内更新过 | 要求责任人补更，迭代负责人抽查一致性 |
| 口径一致性 | 目标、Backlog、状态记录使用同一套工作项和完成定义 | 统一完成定义，修正口径不一致的记录 |
| 变更登记 | 所有范围调整均有时间、内容、影响和确认结论 | 回溯补记近期调整，明确后续登记要求 |
| 阻塞与风险 | 每个阻塞有跟进人和当前处理状态 | 逐项指定跟进人，清理已失效条目 |
| 未完成项处理 | 未完成项有重新评估结论，未默认结转 | 组织评审逐项评估，记录去留与原因 |
检查时优先处理阻断项：目标或验收口径缺失会直接使跟踪失去判断标准，应最先补齐；状态与剩余量长期不更新，会使后续所有比对失真，需要先恢复更新节奏再讨论进度。口径一致性容易被忽略，例如目标按需求描述、Backlog按任务拆分、状态按子任务更新，三者对不上时，跟踪结论会出现互相矛盾。变更与未完成项检查的重点是“有没有留下结论”，而不是调整本身是否合理，结论缺失意味着下一轮规划缺少输入。
这套检查可以在迭代中期做一次抽查，在迭代结束时做一次完整核对。抽查关注时效和阻塞，完整核对关注结论与口径。两项都通过，说明现有依据足以支撑本迭代的跟踪判断；若多次抽查在同一项上不通过，应调整对应角色的更新责任或简化记录方式，让依据维护成为执行的一部分。
常见问题
迭代进行中临时插入需求，跟踪依据怎么保持有效？
临时插入需求时，先由提出方说明原因和影响，产品负责人评估优先级，迭代负责人记录调整内容、调整前后承诺量对比和确认结论。登记完成后再让调整生效，跟踪基准随之更新。若评估后决定不纳入本迭代，也应留下记录，说明评估结论和未纳入原因，避免后续误认为被遗漏。
团队规模小、角色由一人兼任时，依据体系可以简化吗？
可以合并角色，但建议在记录中区分“目标确认”和“过程维护”两类动作。目标确认由产品侧完成，过程维护由迭代负责人完成，即使由同一人执行，也分别留下确认记录和更新记录。这样能防止目标随执行随意漂移，也便于后续回溯判断依据是否完整。
剩余工作量记录和任务状态，哪个更重要？
两者需要配套使用。只有状态没有剩余量，难以判断工作是接近完成还是刚起步；只有剩余量没有状态，难以判断工作是否真正流转。两者结合，才能支撑“按当前速度能否在迭代结束前完成”这类判断。更新频率以每日一次为常见做法，工作项发生实质变化时应即时更新。
迭代结束时未完成的工作项应该怎么处理？
团队应逐项重新评估：是继续留在下个迭代、拆小后重排，还是取消。重新评估的结论连同原因一并记录，作为下一轮规划和本次跟踪收尾的依据。未完成项默认自动结转到下个迭代，会让承诺量失真，也不利于回顾时分析偏差来源。
跟踪依据检查发现多项不通过，应该先补哪一项？
优先处理阻断项。目标或验收口径缺失会直接使跟踪失去判断标准，应最先补齐；状态与剩余量长期不更新，会使后续所有比对失真，需要先恢复更新节奏再讨论进度。若多次抽查在同一项上不通过，应调整对应角色的更新责任或简化记录方式，让依据维护成为执行的一部分。
