如何从迭代目标选择Sprint Backlog条目

2026年11月4日

从迭代目标选择Sprint Backlog条目，关键是把目标先写成可验证的成果，再用统一标准筛选产品Backlog，最后拆成带负责人和完成标志的任务。本文按规划会前、会中、会后三个阶段，给出筛选表、任务表和检查清单，适合正在整理迭代范围的团队直接套用。

Table of Contents

要点总览（TL;DR）

把迭代目标写成可验证的成果，再用目标支撑度、完成定义、协作依赖、迭代内可交付四条标准筛选产品Backlog条目。
入选条目拆成一人或一个小组能在一次协作内推进的任务，每项写清输入、动作、输出、完成标志和负责人。
规划会上按可用人力核对任务总量，逐项确认外部依赖，超出容量的条目移出或拆分，形成团队确认的承诺范围。
迭代结束后未完成的工作重新评估优先级与必要性，再决定是否纳入下一迭代，不默认自动结转。
用目标对应、任务完整性、依赖与容量、承诺范围、未完成工作规则五项清单判断Sprint Backlog是否可执行。

先写清迭代目标与筛选标准

迭代目标是筛选条目的起点。目标写成“完成订单模块重构”这类任务描述，团队只能按清单逐项执行，遇到取舍时缺少判断依据。更有效的写法是面向成果：说明本迭代结束后，哪类用户或业务环节会发生什么可观察的变化，以及用什么方式验证。例如“新用户从注册到完成首单的步骤减少到三步，并在测试环境完成一轮可用性验证”。这样的目标包含对象、变化和验证方式，条目是否值得进入本迭代就有了讨论基础。

目标确定后，需要把判断口径固定下来。建议使用四条标准，对每个候选条目逐项判断：

目标支撑度：条目直接支撑哪个迭代目标；如果只是“顺便做”，应放入候选区而非承诺范围。
完成定义：条目是否有清晰的验收标准，团队能否判断“做完了”。描述模糊的条目先补充定义，再参与筛选。
协作依赖：条目需要哪些角色、外部团队或系统配合，等待时间是否落在本迭代内。
迭代内可交付：按当前信息和团队能力，条目能否在迭代周期内形成可演示或可验证的结果。

把这四条标准落成一张筛选表，规划会前由产品负责人和团队代表共同填写，会上直接作为讨论材料。表格不需要复杂，能支撑取舍即可：

候选条目	支撑的迭代目标	完成定义是否清晰	依赖方与等待时间	本迭代能否交付	判断与理由
示例条目A	目标1	清晰，含验收标准	依赖设计稿，已就绪	能	入选
示例条目B	目标1	缺少异常场景定义	需外部接口联调	待确认	补充定义后再判断
示例条目C	无直接对应	清晰	无	能	移出本迭代

这张表的作用是让“为什么选它”和“为什么不选它”都有记录。规划会上出现分歧时，回到四条标准逐项核对，比反复表达偏好更高效。

从产品Backlog筛出候选条目并排序

有了筛选表，下一步是处理产品Backlog。产品Backlog通常条目多、粒度不一，直接从头到尾逐条讨论会拖长会议。更实际的做法是先按目标支撑度分组：与当前迭代目标直接相关的放一组，间接相关或属于长期方向的放另一组，与目标无关的暂不进入本次筛选。分组完成后，只对第一组逐条填写筛选表的其余字段。

完成定义是第二道筛子。条目只有一句话描述、没有验收标准时，团队无法估算也无法判断完成，应先由产品负责人补充场景、边界和验收条件，再回到筛选流程。条目过大同样需要处理：如果一个条目预计跨越多个迭代，或包含多个可独立验证的结果，应拆成若干较小条目，分别判断是否进入本迭代。依赖未明的条目，先标出依赖对象和预计等待时间，再决定是放入承诺范围还是列为风险项。

排序时建议同时考虑三个因素：对迭代目标的贡献程度、交付风险、以及与其他条目的先后关系。贡献高且风险可控的条目优先；贡献高但依赖外部等待的条目，可以保留但需在规划会上明确等待窗口；贡献一般的条目即使工作量小，也应让位于更直接支撑目标的条目。排序结果和取舍理由一并记录在候选清单中，例如：

顺序	候选条目	排序依据	取舍记录
1	条目A	直接支撑目标1，验收标准完整	进入承诺范围
2	条目D	支撑目标2，依赖已确认	进入承诺范围
3	条目B	支撑目标1，但依赖联调时间未定	列为风险项，会上确认
4	条目E	与目标间接相关，工作量较大	移出本迭代，放回产品Backlog

候选清单形成后，规划会前的准备工作基本完成。此时清单应能回答：每个入选条目服务哪个目标、完成标准是什么、还缺什么信息、有哪些依赖。带着这份清单进入规划会，讨论会集中在容量和依赖确认上，而不是从头梳理需求。

把入选条目拆成可执行的Sprint Backlog任务

入选条目描述的是“要交付什么”，Sprint Backlog任务描述的是“怎么推进”。拆解的粒度以一人或一个小组能在一次协作内推进为宜：任务过大，状态长期停在“进行中”，进度难以判断；任务过细，管理成本上升。一个可操作的经验是，每项任务应有明确的产出物，例如一份设计说明、一个可测试的接口、一组通过的测试用例。

每项任务至少写清四个字段：输入、动作、输出、完成标志。输入说明开始前需要拿到什么，动作说明具体做什么，输出说明产生什么可检查的成果，完成标志说明由谁、按什么条件确认完成。以“完成登录页改版”为例，可拆成：

任务	输入	动作	输出	完成标志	负责人/协作角色
登录页交互稿确认	目标用户场景说明、现有页面问题清单	整理交互方案并组织评审	评审通过的交互稿	产品与设计双方确认签字	设计负责人，产品负责人参与
登录接口改造	交互稿、接口约定文档	调整接口参数与错误码	可联调的接口版本	接口自测通过并提交联调	后端开发
登录页前端实现	交互稿、接口文档	完成页面开发与联调	测试环境可访问的页面	主流程走通，提交测试	前端开发
登录场景测试	测试环境、验收标准	执行主流程与异常场景测试	测试报告与缺陷清单	阻断性缺陷清零	测试负责人

拆解过程中要同步识别依赖。任务之间的先后关系、外部团队的交付时间、环境或数据准备，都应写在任务备注中，并指定跟进人。依赖没有确认前，相关任务可以保留在Sprint Backlog中，但需标注等待状态，避免规划会上把“计划开始”误当成“可以开始”。

在工具承载上，ONES 支持产品负责人按优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；对需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，便于后续处理和跟踪。这一流程与上述“先确认条目、再拆任务”的顺序一致，团队可以把筛选表和任务表直接对应到迭代工作项与子任务上。

规划会上确认容量、依赖与承诺范围

规划会的核心任务不是继续添加条目，而是校验已有候选范围是否可执行。会前应准备可用人力与时间口径：本迭代有哪些成员参与、每人有多少可投入时间、是否存在休假或支持其他事务的安排。用任务总量对照可用容量，重点看关键角色是否过载，例如测试资源集中在迭代末期、某位开发同时承担多项联调任务。

容量核对之后，逐项确认外部依赖。对每个依赖写明提供方、约定时间和备选方案；等待时间无法落在迭代内的，相关条目应移出承诺范围或拆出可独立交付的部分。超出容量的条目同样处理：优先移出目标支撑度较低的条目，其次拆分条目，把必须在本迭代验证的部分留下。取舍结果当场记录，避免会后各自理解不同。

会议结束前形成团队确认的承诺范围，并列出遗留问题清单：哪些条目待补定义、哪些依赖待回复、哪些风险需要持续跟踪。承诺范围应包含条目清单、任务负责人和关键完成标志，遗留问题则明确跟进人和下次确认时间。ONES 支持将需求和相关任务规划至迭代并分配负责人，团队可以在同一迭代视图中核对范围与责任人，减少会后再对齐的成本。

规划会后保持可执行粒度

Sprint Backlog在迭代执行中会持续变化，维护规则需要在规划会上就说明。日常做法是每次协作后更新任务状态与剩余工作，让看板反映真实进展；每日站会围绕阻塞项和依赖变化展开，而不是逐条汇报已完成事项。ONES 的敏捷看板可用于管理任务状态，团队在站会中借助看板对齐进度与风险，这一用法适合把状态更新固定在日常节奏里。

新增条目进入当前迭代前，先做准入判断：它是否直接服务当前迭代目标；如果不服务，应放入产品Backlog等待下个迭代。确需加入的紧急条目，要记录加入原因、影响的范围和需要调整的原有任务，并同步给受影响的角色。范围变更不隐藏，变更记录本身就是后续复盘的材料。

迭代结束时，未完成工作应重新评估优先级和必要性，再决定是否纳入下一迭代，不默认自动结转。重新评估时看三个问题：该工作是否仍服务下一迭代目标、完成定义是否已经清晰、依赖是否已经解除。三个问题都有明确答案，才进入下一轮候选清单；否则放回产品Backlog或关闭。

一个完整示例：从目标到任务表

以下为演示情景，用于说明方法如何落地，不代表真实项目数据。某团队本迭代目标为：“让新用户在测试环境完成从注册到首单的流程，主路径步骤不超过三步，并收集一轮可用性反馈。”规划会前，产品负责人从产品Backlog中整理出五个候选条目：注册表单简化、首单引导页、短信验证码接口调整、历史订单导出、后台报表样式优化。

按筛选表判断：注册表单简化和首单引导页直接支撑目标，完成定义清晰，进入候选；短信验证码接口调整是注册流程的前置依赖，但需外部短信服务商配合，列为风险项；历史订单导出与目标无关，移出本迭代；后台报表样式优化工作量小但目标支撑度低，同样移出。候选清单记录了取舍理由，规划会上不再重复讨论无关条目。

拆解阶段，注册表单简化拆成交互稿确认、前端表单改造、校验规则测试三项任务；首单引导页拆成引导文案确认、页面开发、可用性测试准备三项任务。每项任务写明输入、输出和完成标志，并指定负责人。短信验证码接口调整保留为依赖任务，标注等待服务商回复的时间窗口。

规划会上，团队按可用人力核对任务总量，发现测试角色在迭代后期集中承担校验和可用性测试，容量偏紧。团队决定把可用性测试准备拆出部分工作提前到迭代中期，并将后台报表样式优化正式移出。最终承诺范围包含两个目标条目及其任务，短信验证码依赖作为风险项持续跟踪，遗留问题清单记录服务商回复时间和备选验证方案。

完成检查：Sprint Backlog是否可执行

规划会结束前，用以下清单逐项核对。任何一项无法确认，都应回到对应环节补充，而不是带着模糊范围进入执行。

检查项	判断标准	确认方式
目标与条目对应关系	每个入选条目都能指出支撑的迭代目标；无对应目标的条目已移出或记录理由	对照筛选表逐条检查
任务完整性	每项任务都有负责人、输入、输出和完成标志	抽查任务表，缺失字段当场补充
依赖与容量	外部依赖已确认提供方和时间；关键角色任务量未超出可用容量	逐项核对依赖清单与人力口径
承诺范围	团队对入选条目和任务范围达成一致，遗留问题有跟进人	会上口头确认并记录
未完成工作规则	迭代结束时重新评估，不默认自动结转；新增条目有准入判断	维护规则已写入团队约定

这份清单也可以作为迭代中期的自查工具：当范围发生变化或进度偏离时，回到清单检查哪一项前提被打破，再决定调整任务还是调整承诺范围。

常见问题

迭代目标写成了任务清单，还能用来筛选Sprint Backlog条目吗？

可以先用它做初步分组，但建议在规划会前补写成成果表述。任务清单式目标只能说明要做什么，遇到“两个条目只能选一个”时缺少判断依据。补写时补上三件事：本迭代结束后哪类用户或业务环节发生什么可观察的变化、用什么方式验证、验证结果由谁确认。补完后回到四条筛选标准逐条判断，原先按任务清单选出的条目可能需要调整。

候选条目缺少验收标准，是直接移出还是先补定义？

视条目与迭代目标的关系而定。直接支撑目标且工作量可控的条目，优先由产品负责人补充场景、边界和验收条件，再回到筛选流程；补充后仍无法判断完成的，列为遗留问题，不进入承诺范围。与目标关系间接的条目，直接放回产品Backlog，等定义清晰后再参与后续迭代的筛选。无论哪种处理，取舍理由都应记录在候选清单中。

规划会上发现任务总量超出团队容量，应该先砍条目还是先拆任务？

先按目标支撑度排序，移出支撑度较低的条目，再考虑拆分。拆分适用于必须在本迭代验证、但可以分阶段交付的条目，把本迭代能完成的部分留下，其余放回产品Backlog。关键角色过载时，还要检查任务分配是否集中，例如测试工作是否都压在迭代末期，必要时调整任务顺序或提前准备输入。调整结果当场记录，并同步给受影响的角色。