迭代执行中Sprint Backlog如何随新信息更新

迭代执行中收到新信息，先别急着改Sprint Backlog。先判断它属于澄清还是范围变化：澄清只补充验收条件、任务拆分、依赖与阻塞说明，不改迭代目标和承诺范围；范围变化则要由产品负责人和团队评估，走替换、移出或拆分流程并留下决策记录。迭代结束时，未完成项逐项重新评估去向，不默认自动结转。

要点总览（TL;DR）

• 拿到新信息先归类：是否改变迭代目标、承诺交付物或验收标准，三项都不动按澄清处理，任一项变动进入范围变化流程。
• 澄清类更新由执行者当天登记变更内容、来源、影响工作项、责任人和时间，产品负责人确认验收口径，Scrum Master 跟进阻塞。
• 范围变化由产品负责人定优先级、团队评估可行性，采用替换等量工作、移出产品待办或拆分到后续迭代处理，并记录结论、理由、影响范围和通知对象。
• 新依赖与阻塞发现当天登记到对应工作项，每日站会同步状态，超出团队可控范围时带齐阻塞描述、已尝试动作、影响和所需支持向上升级。
• 未完成项在迭代结束逐项评估剩余价值、剩余工作量、拆分可行性和下个迭代优先级，选择回退、拆分带入、关闭或合并，不默认自动结转。

先判断：哪些更新是澄清，哪些会改变迭代范围

拿到新信息后，第一件事是归类。归类的口径只有一个：这条信息是否改变迭代目标、承诺范围或验收标准。三项都不动，属于澄清；动了其中任何一项，按范围变化处理。先归类再动手，能避免把范围变化当成细节补充悄悄塞进迭代，也能避免把正常澄清拖成一场评审会。

澄清类更新通常发生在实现层面。典型情形包括：验收条件从“支持导出”细化为“支持按筛选条件导出 CSV，单次不超过 5 万行”；一个开发任务拆成前后端两个子任务；补充说明某功能依赖第三方接口的联调时间；调整实现方式但交付物不变。这类信息让工作项更清楚，迭代承诺不受影响。

范围变化类更新则触及承诺本身。典型情形包括：迭代中途新增一个需求；迭代目标从“完成支付主流程”调整为“完成支付主流程并支持退款”；交付物增减；承诺日期提前或延后。这类信息需要评估和决策，不能由执行者单方面写入。

判断时可以依次问三个问题：这条信息是否改变迭代目标？是否增减了承诺交付的内容？是否改变了已达成一致的验收标准？三个答案都是“否”，按澄清处理；任一为“是”，进入范围变化流程。下表给出分类判断与对应处理路径。

判断问题	澄清类更新	范围变化类更新
是否改变迭代目标	否	是
是否增减承诺交付物	否	是
是否改变验收标准	否，只细化不改变	是，标准本身调整
典型情形	验收条件细化、任务拆分、依赖与阻塞说明、实现方式调整	新增需求、目标调整、交付物增减、承诺日期变化
处理路径	执行者直接登记，产品负责人确认验收口径	产品负责人与团队评估，决策后记录并通知
决策角色	执行者登记，Scrum Master 跟进阻塞	产品负责人定优先级，团队评估可行性

澄清类更新怎么落到Sprint Backlog上

澄清类更新的目标是让信息可追溯，同时不扰动迭代范围。操作上分三步：先登记，再确认，最后同步。登记由发现信息或负责该工作项的成员完成，确认由产品负责人把关验收口径，同步通过每日站会或工作项评论完成。

每条澄清更新至少记录五个字段：变更内容、信息来源、影响的工作项、责任人、登记时间。变更内容写清楚改了什么，例如“验收条件增加导出格式为 CSV”；信息来源写清是客户反馈、技术评审还是联调发现；影响的工作项关联到具体需求或子任务；责任人写明谁负责落实；时间记录登记日期，便于回溯。

具体动作包括：在对应工作项下补充验收条件，把模糊描述改成可验证的表述；把过大的任务拆成子任务，明确每个子任务的完成标志；在依赖说明中标注外部接口、环境或团队，并写明期望就绪时间；发现阻塞时登记阻塞类型、影响范围和当前状态。任务拆分可借助子任务完成，让后续处理和跟踪有明确载体。

责任人分工要清楚：执行者负责登记自己发现的澄清信息；Scrum Master 跟进阻塞类澄清，推动解除并同步状态；产品负责人确认验收口径的细化是否仍在原承诺范围内。完成标志是相关成员在工作项上可见更新，且工作项状态与说明一致——说明里写了什么，看板和状态就反映什么。

范围变化怎么评估、决策与记录

范围变化不能靠口头约定。评估输入包括三项：变更内容本身、对迭代目标的影响、所需工作量与依赖。团队先判断可行性：在剩余时间内完成这项变化，需要挤占哪些工作，是否引入新的外部依赖。产品负责人据此定优先级，必要时与相关方确认承诺日期或交付范围。

处理方式有三种。替换等量工作：新增一项就移出一项同等规模的工作，保持迭代总量稳定。移出到产品待办：把受影响的工作项退回产品待办列表，留待后续迭代规划。拆分到后续迭代：把变化内容拆小，部分在本迭代完成，其余进入下个迭代。三种方式可以组合使用，选择依据是迭代目标是否仍可达成。

决策记录要写清四件事：结论是什么、理由是什么、影响哪些工作项和交付物、通知了哪些人。记录位置建议放在迭代文档或工作项评论中，与工作项关联，避免决策只存在于会议记忆里。记录模板可以这样组织：变更描述、评估结论、处理方式、影响范围、决策人、通知对象、决策日期。决策完成后，同步更新Sprint Backlog 中相关工作项的状态和说明，让看板反映真实承诺。

新依赖与阻塞在迭代中的登记与跟进

新依赖和阻塞要在发现当天登记，位置是对应的工作项，而不是只写在聊天记录里。登记时标注阻塞类型（外部依赖、环境问题、技术难题、等待决策等）、影响范围（影响哪个需求、哪个交付节点）和当前状态。当天登记的价值在于让问题进入团队可见的范围，而不是等到站会才被提起。

跟进节奏固定在每日站会：逐项同步阻塞状态，明确解除责任人和期望解除时间。站会只同步状态和下一步动作，详细讨论放到会后。对于持续超过一天的阻塞，Scrum Master 要主动跟进，确认责任人是否在推进，期望时间是否仍然成立。

升级条件要事先约定：当阻塞超出团队可控范围，例如依赖外部供应商、跨部门资源或需要管理层决策时，向对应层级升级。升级时带上四项信息：阻塞描述、已尝试的解决动作、对迭代目标的影响、需要的支持。升级不是推卸责任，而是把决策权交给能解除阻塞的人。

阻塞解除后要做收尾：更新工作项状态，补充解除说明和实际解除时间，评估是否已经影响迭代目标。如果影响已经发生，转入范围变化的评估流程，而不是默默接受进度偏差。迭代执行中，团队通过看板管理任务状态，在每日站会借助看板对齐进度与风险，这套动作与阻塞登记配合，能让问题从发现到解除形成闭环。

未完成项如何重新评估而非默认结转

迭代结束时，未完成项要逐项重新评估，不默认自动结转到下个迭代。默认结转的问题在于：它把“没做完”当成“还要做”，跳过了价值判断，下个迭代的容量被历史包袱占用，优先级也无法重新排序。

重新评估看四个判断项：剩余价值，这项工作对当前目标是否仍然重要；剩余工作量，距离完成还差多少；拆分可行性，能否拆出一部分先交付；下个迭代优先级，与下个迭代的其他候选工作相比排在哪里。四项判断完成后，再选处理选项。

处理选项有三类：回退产品待办，重新参与优先级排序；拆分后部分带入下个迭代，先交付可用的部分；关闭或合并，确认不再需要的工作项关闭，重复的工作项合并到其他条目。每个未完成项都要有明确去向，不能停留在“待定”状态。

决策由产品负责人主导，团队提供工作量和拆分可行性判断。记录写在工作项本身和迭代回顾材料中，说明去向和理由。向相关方说明时，重点讲清楚哪些承诺未达成、原因是什么、下个迭代如何安排，而不是只报一个完成率。

一个迭代中的更新示例

以下为演示情景。某团队进行一个两周迭代，目标是完成订单查询功能。迭代第 4 天，开发人员在联调时发现订单服务依赖的权限接口由另一个团队提供，对方尚未排期。按分类规则，这属于澄清类更新中的依赖说明：迭代目标和交付物未变。开发人员当天在工作项下登记依赖说明，标注外部团队、期望就绪时间和影响范围；Scrum Master 在站会上同步，并联系对方团队确认排期。第 6 天确认接口无法在本迭代内就绪，阻塞超出团队可控范围，Scrum Master 向项目负责人升级，带上阻塞描述、已尝试动作和对迭代目标的影响。

第 7 天，产品负责人收到客户反馈，希望订单查询同时支持按时间范围筛选。这是新增需求，改变承诺范围，属于范围变化。产品负责人与团队评估：新增筛选约需 2 人天，当前迭代剩余容量不足以同时完成原定导出功能。团队提出替换方案：将导出功能移出到产品待办，本迭代改为完成时间范围筛选。产品负责人确认优先级后拍板，记录决策结论、理由、影响的两个工作项和通知对象，同步更新看板。

迭代结束时，权限接口相关任务仍未完成。团队逐项评估：该任务剩余价值高，但依赖外部接口，拆分可行性低，下个迭代优先级取决于接口排期。处理结果为回退产品待办，标注依赖状态，待接口就绪后重新规划。时间范围筛选按计划完成，导出功能留在产品待办等待排序。整个过程中，澄清项有登记字段，范围变化有决策记录，未完成项有明确去向。

完成检查：更新机制是否运转到位

迭代结束后，用下面这份清单核对更新机制是否真正执行。清单按动作逐项检查，每项都能在工作项、文档或会议记录中找到对应证据。

检查项	核对内容	证据位置
分类判断有记录	每次新信息都有澄清或范围变化的归类结论	工作项评论或迭代文档
澄清字段完整	变更内容、来源、影响工作项、责任人、时间五项齐全	对应工作项字段
范围变化经过评估	有评估输入、决策角色和处理方式	决策记录
决策记录可追溯	结论、理由、影响范围、通知对象均已记录	迭代文档或工作项
阻塞当天登记	新依赖与阻塞在发现当天进入工作项	工作项阻塞说明
阻塞按节奏跟进	站会同步状态，责任人和期望时间明确	站会记录
升级有据可查	超出团队范围的阻塞有升级记录和所需支持	升级记录
未完成项逐项评估	每项都有剩余价值、工作量、拆分和优先级判断	迭代回顾材料
未完成项有去向	回退、拆分、关闭或合并，无“待定”项	工作项状态

清单中任何一项找不到证据，说明对应环节还停留在口头约定。把这些动作固定到工作项状态和迭代文档中，更新机制才能在下个迭代继续运转。

常见问题

迭代中客户临时提出一个小改动，工作量不到半天，还需要走范围变化流程吗？

判断依据是这条改动是否改变迭代目标、承诺交付物或验收标准，与工作量大小无关。如果改动只是把已有功能的验收条件写得更具体，例如明确导出格式或字段范围，按澄清处理，执行者登记后由产品负责人确认口径即可。

如果改动新增了原本不在承诺范围内的内容，即使只需半天，也属于范围变化。此时由产品负责人判断是否值得占用本迭代容量，团队评估可行性，常见做法是替换等量工作或移出到产品待办。小改动直接塞进迭代，会让承诺范围悄悄扩大，后续排期和进度判断都会失真。

迭代中途产品负责人调整了优先级，但交付内容没变，这算澄清还是范围变化？

交付内容不变、只调整工作顺序，通常按澄清类更新处理：在工作项上更新优先级说明和调整理由，团队据此安排执行顺序，迭代目标和承诺范围保持不变。

需要留意一种情况：优先级调整导致某项承诺工作在本迭代内无法完成。这时实际结果已经影响承诺范围，应按范围变化处理，由产品负责人明确哪项工作移出、移到哪里，并记录决策。判断的关键是看最终交付是否变化，而不只看动作名称。

阻塞在迭代最后两天才解除，剩余工作已经做不完了，应该怎么处理？

先更新阻塞状态并补充解除说明和实际解除时间，然后评估对迭代目标的影响。影响已经发生，就转入范围变化的评估流程，由产品负责人和团队判断剩余工作能否在迭代内完成、需要挤占哪些其他工作。

如果确认无法完成，按未完成项处理：在迭代结束时逐项评估剩余价值、剩余工作量、拆分可行性和下个迭代优先级，选择回退产品待办、拆分后部分带入或关闭合并。把进度偏差如实记录并向相关方说明，比在最后两天压缩测试或跳过验收更可控。

团队规模小、没有专职 Scrum Master，阻塞跟进和升级由谁负责？

角色可以合并，职责不能空缺。小团队通常由迭代负责人或团队指定的协调人承担阻塞跟进：每日站会逐项同步阻塞状态，明确解除责任人和期望时间，超出团队可控范围时负责升级。

升级对象按组织实际情况确定，可以是产品负责人、项目负责人或能调动外部资源的管理者。升级时带齐阻塞描述、已尝试的解决动作、对迭代目标的影响和需要的支持。把这项职责写进团队工作约定，避免阻塞出现后无人推动。

未完成项回退产品待办后，下个迭代规划时还要重新评估吗？

需要。回退只是把工作项放回候选池，不代表下个迭代必须优先做。下个迭代规划时，它要和其他候选工作一起参与优先级排序，评估依据包括当前业务价值、依赖是否就绪、工作量估算是否仍然成立。

回退时建议在工作项上保留说明：为什么未完成、依赖状态如何、当时的评估结论。这些信息能帮助下个迭代规划时快速判断，避免同一项工作反复被带入又反复完不成。