Sprint Backlog执行计划怎么围绕迭代目标制定

围绕迭代目标制定Sprint Backlog执行计划，关键动作有四步：先把迭代目标写成可验证的完成条件，再按目标贡献度筛选条目并控制范围，然后把条目拆到一到两天可完成的任务，最后在规划会后持续复核粒度与阻塞。本文面向具体迭代运行，适用于规划会前后整理Sprint Backlog的场景；文中会自然提及ONES在任务拆解与迭代状态管理上的衔接方式。

要点总览（TL;DR）

• 先把迭代目标写成包含对象、范围和验收口径的完成条件，团队才能据此判断条目该不该进Sprint Backlog。
• 筛选条目看目标贡献度：必要且不可替代的纳入，贡献间接的留在产品Backlog并记录原因，范围与团队历史完成水平做量级匹配。
• 条目拆到一到两天可完成的任务，每个任务标注输入、唯一负责人、输出和他人可核验的完成标志，依赖与阻塞同步标出。
• 规划会前产品负责人备好目标草稿与候选清单，会中团队确认范围与拆解，会后同步计划、回写未纳入条目并记录变更。
• 执行期在站会与看板上复核粒度与阻塞；未完成工作逐条重新评估，按对下一迭代目标的贡献决定去向，不默认结转。

先写清迭代目标与完成条件

迭代目标是筛选条目的依据，写不清目标，Sprint Backlog就容易变成需求清单的堆叠。一个可用的迭代目标应包含三个要素：对象（这次迭代要改变哪个业务对象或用户场景）、范围（覆盖哪些功能或环节、明确不包含什么）、验收口径（由谁、依据什么标准判断达成）。三者缺一，团队在规划会上就很难对“做完没有”形成一致判断。

把模糊目标改写为可验证完成条件，可以用一个简单的改写动作：把“优化下单体验”这类表述，补成“完成下单页地址填写与支付方式选择的改版，新流程在测试环境通过主流程用例，客服侧收到新版操作说明”。改写后的表述包含交付物、验证方式和接收方，团队能据此判断工作是否收口。

目标与Sprint Backlog条目之间应保持可追溯的对应关系。建议在整理时给每个候选条目标注它支撑目标的哪一部分，例如“支撑地址填写改版”或“支撑支付方式选择”。标注不上的条目，要么与本迭代目标无关，应留在产品Backlog；要么说明目标遗漏了重要内容，需要回到目标层面补充。这样，目标、条目、任务形成一条可回溯的线索，后续范围讨论也有共同参照。

从产品Backlog筛选支撑目标的条目

筛选条目的判断标准是目标贡献度，而非条目本身的优先级高低。产品负责人依据需求优先级把候选条目规划到本迭代后，团队在规划会上逐条确认：这条工作对达成迭代目标是否必要？去掉它目标是否仍可达成？必要且不可替代的条目进入Sprint Backlog；贡献间接、可以延后的条目留在产品Backlog，并记录延后原因。

范围控制需要与容量做粗略匹配。规划会前，团队可依据历史完成情况估算本迭代可投入的工作量，再对照候选条目的规模做取舍。这里追求的是量级上的合理，而非精确到小时的排期：如果候选条目总量明显超出团队以往一个迭代的完成水平，就应优先保留直接支撑目标核心部分的条目，把边缘条目移出。容量判断的依据应写进计划，便于会后复盘时对照。

被排除的条目要有明确去处，避免在迭代中途被悄悄加回。常见处理是：在产品Backlog中保留原优先级并补充“未纳入本迭代的原因”；若条目因依赖外部条件而暂缓，标注依赖对象与预计可评估时间。规划会结束时，Sprint Backlog应是一份范围已锁定、每条都能说明目标贡献的清单。

把条目拆成可执行的任务与完成标志

条目层只回答“做什么”，任务层要回答“谁在什么输入下做什么动作、产出什么、怎样算完成”。拆解粒度以一到两天可完成为参考：超过这个粒度的任务，通常说明其中还包含未识别的环节，应继续拆分；明显小于半天的任务，可以合并到相邻任务中，避免计划表被琐碎动作淹没。粒度判断服务于执行中的进度可见性，团队可根据自身节奏调整。

每个任务建议标注四项信息：输入（依赖的文档、接口、设计稿或前置任务产出）、负责人（唯一责任人，协作人另列）、输出（可检查的产物，如接口联调记录、测试用例集、页面截图）、完成标志（他人可核验的判断条件，如“主流程用例全部通过”）。四项齐全，任务才具备交接条件；缺少完成标志的任务，在执行中容易产生“做完了但没人认”的争议。

依赖与阻塞项应在拆解时同步标出。做法是给任务增加“依赖”字段，写明依赖的任务编号或外部对象，并把当前不可启动的任务标记为阻塞状态，注明阻塞原因与解除条件。这样在每日站会上，团队可以直接围绕阻塞项讨论，而不必逐条询问进度。

任务	输入	负责人	输出	完成标志	依赖/阻塞
地址填写页改版开发	交互稿、字段校验规则	开发A	测试环境可访问的页面	字段校验按规则生效，自测通过	依赖交互稿定稿
支付方式选择联调	支付接口文档、页面改版结果	开发B	联调记录	两种支付方式下单成功各一次	阻塞：等待支付渠道测试账号
主流程用例编写与执行	验收标准、改版页面	测试C	用例集与执行记录	主流程用例全部通过并记录结果	依赖前两项任务完成

在工具层面，ONES支持在需求与验收标准达成一致后，由设计、研发、测试人员利用子任务拆分需求，便于后续处理和跟踪；对功能复杂的需求，也可用子工作项拆解并关联研发、测试任务。这类承载方式适合把上述任务拆解表落到具体工作项上，具体字段与配置以团队实际使用的版本为准。

规划会前后的分工与交接

规划会前的准备工作决定会议效率。产品负责人负责整理候选条目、标明优先级与目标贡献，并提前发出迭代目标草稿；Scrum Master负责确认会议时间、参与人和所需材料，收集团队对容量的初步判断；开发团队提前浏览候选条目，标记技术疑问与明显依赖。会前准备到位的标志是：参会者拿到目标草稿和候选清单，能带着问题进会。

规划会中，团队共同确认迭代目标与验收标准，逐条决定纳入范围，完成条目到任务的初步拆解，并认领负责人。会议结束时形成的共识应包括：目标表述、Sprint Backlog条目清单、任务拆解结果、阻塞项清单。产品负责人对范围与优先级拍板，开发团队对拆解粒度与工作量判断负责，Scrum Master保障讨论围绕目标展开并记录结论。

角色	会前交付物	会中动作	会后交付物
产品负责人	迭代目标草稿、候选条目与优先级	确认范围与验收标准	更新后的产品Backlog、范围变更记录
Scrum Master	会议安排、材料清单	引导讨论、记录结论与阻塞项	会议结论纪要、计划同步通知
开发团队	容量初判、技术疑问清单	拆解任务、认领负责人	任务拆解表、阻塞项与依赖说明

会后同步的重点是让计划进入可执行状态：Scrum Master把确认后的目标、条目和任务拆解结果发布到团队可见的位置；产品负责人把未纳入条目及原因回写到产品Backlog；开发团队补齐任务字段。会后如发生范围调整，应记录变更内容、提出人、影响的目标部分和团队确认结果，避免口头变更导致计划与实际脱节。

规划会后保持可执行粒度的复核

计划的可执行性会在执行中衰减：任务推进后暴露出新的子环节，外部依赖解除时间变化，都会让原有粒度变粗。复核动作可以放在每日站会中完成，围绕三个问题：今天要推进的任务是否仍有明确的完成标志？是否有任务因阻塞无法启动、阻塞原因是否已记录？新发现的工作是否超出原任务范围、需要拆出新任务？站会输出应是任务状态的更新和阻塞项的跟进人，而非泛泛的进度汇报。

当条目粒度变粗或范围发生变化时，调整方式应回到目标层面判断：新增工作是否服务于当前迭代目标？如果是目标内遗漏的必要工作，拆出任务并评估对容量的影响；如果超出目标范围，交由产品负责人决定是否替换掉贡献较低的条目，替换动作记入变更记录。范围只增不减是计划失控的常见原因，替换而非叠加是更稳妥的处理方式。

未完成工作的处理需要重新评估，而非默认结转到下一迭代。迭代结束时，团队应逐条检查未完成条目：未完成原因是估算偏差、阻塞未解除还是范围变更？该条目对下一迭代目标是否仍有贡献？依据评估结果决定重新纳入、拆分后部分纳入或退回产品Backlog。把“默认结转”改成“逐条评估”，可以避免Sprint Backlog在多个迭代间累积成一笔说不清的欠账。

在执行期，ONES的敏捷看板可用于管理任务状态，每日站会借助看板对齐进度与风险；燃尽图可作为评估研发效率的参考。这些视图帮助团队把复核动作建立在可见的状态之上，具体口径以团队配置为准。

一个迭代的执行计划示例

以下为演示情景，用于说明从目标到复核的完整过程，不代表真实项目数据。

迭代目标与完成条件：某电商团队的两周迭代目标为“完成下单页地址填写与支付方式选择改版”。完成条件写成：新流程在测试环境通过主流程用例；客服团队收到新版操作说明；旧版入口保留一个迭代作为回退。对象、范围、验收口径齐备，团队可据此判断达成与否。

条目筛选：候选清单包含地址填写改版、支付方式选择改版、订单列表筛选优化、优惠券文案调整四条。前两条直接支撑目标，纳入范围；订单列表筛选优化与目标无关，留在产品Backlog并注明原因；优惠券文案调整贡献间接，延后处理。团队对照历史完成水平判断容量可承载前两条，范围就此锁定。

任务拆解结果：地址填写改版拆为交互稿确认、页面开发、字段校验自测三项；支付方式选择改版拆为接口联调、页面开发、联调记录整理三项；测试侧拆为主流程用例编写与执行一项。每项标注输入、负责人、输出与完成标志，支付联调因等待渠道测试账号被标记为阻塞。

会后复核发现的问题与调整：执行到第三天，站会发现地址填写页新增了“地址联想”需求，原任务粒度变粗。团队判断该需求服务于目标中的地址填写体验，拆出独立任务并评估工作量；为保持容量平衡，产品负责人决定把优惠券文案调整彻底移出本迭代并记录变更。支付联调的阻塞在第五天解除，任务恢复推进。迭代结束时，主流程用例全部通过，目标达成；地址联想的一个边缘场景未完成，团队评估后将其拆分，部分纳入下一迭代，其余退回产品Backlog。

完成检查：执行计划是否可落地

整理完Sprint Backlog后，可用以下清单逐项核对。检查以“能否据此执行和判断”为标准，任一项不通过，回到对应环节修正。

检查维度	检查项	通过标准
目标	迭代目标是否包含对象、范围与验收口径	团队能一致回答“怎样算达成”
条目	每条Sprint Backlog条目是否标注目标贡献	无标注不上、无法说明贡献的条目
任务	每个任务是否有一到两天可完成的粒度	超粒度任务已继续拆分或说明原因
责任人	每个任务是否有唯一负责人	协作人另列，无“大家一起做”的任务
完成标志	每个任务是否有他人可核验的完成标志	标志具体到可检查的产物或结果
依赖与阻塞	依赖与阻塞项是否标注原因和解除条件	阻塞项有跟进人，站会可据此讨论
范围变更	范围调整是否有记录与确认	变更内容、影响目标部分、确认人齐全
未完成工作	是否有逐条重新评估的规则	明确不默认结转，评估后决定去向

四层一致性是检查的核心：目标中的每个完成条件都能找到对应条目，每个条目都能落到具体任务，每个任务都有负责人和完成标志。四层对得上，执行计划才具备落地条件；对不上的地方，往往就是执行期争议的来源。

常见问题

迭代目标在规划会上被临时调整，已经拆好的Sprint Backlog怎么办？

目标调整后，先判断影响范围：如果只是验收口径细化，原有条目和任务通常可以保留，补充完成标志即可；如果对象或范围发生变化，应回到条目层重新核对每条工作的目标贡献，把不再支撑新目标的条目移出并记录原因，再对保留条目重新拆解任务。

调整动作应在会上形成明确结论，包括新目标表述、条目增删清单和受影响的负责人，会后同步给团队。已经启动的任务若与新目标无关，由产品负责人决定停止还是完成收尾，避免团队在方向变化后继续投入。

团队规模较小、角色兼任时，规划会前后的分工怎么简化？

角色可以兼任，交付物不宜省略。小团队中产品负责人可能同时承担Scrum Master的引导职责，此时仍建议把两类动作分开做：会前准备候选条目与目标草稿，会上引导讨论并记录结论。开发团队人数少时，任务拆解可以由全体共同完成，但每个任务仍需落到唯一负责人。

简化的重点是减少会议和文档层级，而非取消确认环节。目标与验收标准、条目范围、任务完成标志这三项确认保留下来，计划就具备执行基础。

任务拆到一到两天仍然估不准，是否要拆得更细？

估不准通常来自信息不足，而非粒度不够。先检查任务是否缺少输入或完成标志：输入不明确的任务，负责人无法判断工作量；完成标志模糊的任务，边界难以界定。补齐这两项后仍偏大的任务，再继续拆分。

继续拆到半天以内也有代价，计划表会变得琐碎，站会讨论成本上升。更实用的做法是保留一到两天的粒度，在执行中暴露新环节时再拆出新任务，并把这次偏差记入复盘，用于下次估算参考。

迭代中途插入紧急需求，如何判断是否替换现有条目？

先看紧急需求是否服务于当前迭代目标。属于目标内遗漏的必要工作，拆出任务并评估对容量的影响，必要时替换掉贡献较低的条目；超出目标范围的，交由产品负责人决定是否纳入，纳入就同步移出等量工作。

替换动作要记录变更内容、提出人、影响的目标部分和确认结果。只增不减会让Sprint Backlog逐步超出容量，团队在迭代后期难以收口。

未完成工作重新评估时，具体看哪些信息？

逐条看三项：未完成原因（估算偏差、阻塞未解除还是范围变更）、剩余工作的实际规模、该条目对下一迭代目标的贡献。三项信息齐备，才能判断是重新纳入、拆分后部分纳入还是退回产品Backlog。

评估结论应写回条目并说明理由，下一迭代规划时可直接参考。把默认结转改成逐条评估，Sprint Backlog才不会在多个迭代间累积成说不清的欠账。