从迭代目标选择Sprint Backlog条目，关键是把目标写成可验证的结果，再据此判断哪些产品待办条目直接支撑它。本文按规划会前后的实际顺序，给出筛选口径、挑选步骤、拆解方法、角色分工和会后检查清单，适用于单个迭代的条目整理。条目整理与状态跟踪环节可借助ONES的迭代与工作项管理承载，方法本身不依赖特定工具。
要点总览（TL;DR）
- 先把迭代目标写成一句可验证的结果陈述，包含对象、变化和判断依据，再拆成2–4条支撑结果，作为条目入选与排除的统一口径。
- 规划会前由产品负责人按支撑度初筛产品待办，逐条回答支撑哪条结果、是直接还是间接支撑，输出带入选理由和依赖的候选清单。
- 入选条目按交付路径拆成迭代内可完成、可独立验证的工作项，补齐验收标准、负责人和估算，标注依赖与风险后排出执行顺序。
- 产品负责人、Scrum Master、开发团队在会前、会中、会后各有明确交付物，会中变更当场记录，避免清单版本不一致。
- 规划会后在站会中检查粒度与阻塞，未完成条目回到产品待办重新评估，不默认结转到下一迭代。
从迭代目标到Sprint Backlog：先定筛选口径
筛选条目的前提是有一个能判断“支撑与否”的目标。迭代目标如果写成“提升用户体验”“优化支付流程”这类方向描述，团队成员对哪些条目该进、哪些该出的判断会各不相同，规划会容易变成逐条争论。把目标改写成一句可验证的结果陈述，筛选才有共同依据。
可验证的结果陈述通常包含三个要素：对象（哪个用户、哪个环节）、变化（期望发生什么改变）、判断依据（用什么数据或现象确认达成）。例如“新用户首次下单流程的完成率从当前的基线提升，主要流失步骤的报错清零”，比“优化下单体验”更容易对应到具体条目。目标不必写得很长，一句话说清即可，但其中的对象和判断依据要具体到团队能指着它讨论。
一句目标往往还需要拆成2–4条支撑结果或用户价值，才能对应到不同条目。拆法有两种常见路径：按用户旅程拆，如“能顺利找到商品”“能完成支付”“支付失败时知道原因”；按业务结果拆，如“减少某类客服工单”“缩短某环节耗时”。每条支撑结果都应能回答“达成它，用户或业务会看到什么”。支撑结果过多说明目标过大，需要考虑缩小迭代范围；只有一条且无法再拆，则要检查目标是否过于笼统。
据此形成条目筛选口径，建议写成一张简表，在规划会上直接使用：
| 判断问题 | 入选条件 | 排除或暂缓条件 |
|---|---|---|
| 是否直接支撑某条支撑结果 | 能指出对应哪条支撑结果，并说明支撑方式 | 与所有支撑结果均无直接关系 |
| 是否在本迭代内可交付 | 团队评估后可在迭代周期内完成并验证 | 依赖外部团队排期、周期明显超出迭代长度 |
| 是否具备验收条件 | 能写出可检查的验收标准 | 需求方向未定、验收标准无法描述 |
| 是否与其他入选条目重复 | 与其他条目无功能重叠 | 与已入选条目重复，合并处理 |
这张表的作用是让“为什么选它”有统一答案。口径确定后，规划会上的讨论从“我觉得这个重要”转为“它对应哪条支撑结果、能否在迭代内验证”，筛选效率会明显提高。
筛选条目的操作步骤：输入、动作与输出
口径确定后，挑选条目是一项有输入、有动作、有输出的具体工作，建议在规划会前由产品负责人牵头完成初筛，会上再由团队确认。
输入准备。需要三类材料：一是已按优先级排列的产品待办，条目描述至少包含背景和目标用户；二是上一节形成的目标陈述与筛选口径；三是团队容量，包括本迭代可用人力、已有承诺占用的时间，以及必要的休假和支援安排。容量数据缺失时，筛选容易选出超出团队承受范围的条目，因此这一步不能省略。
逐条判断支撑度。按产品待办的顺序逐条过，对每条回答两个问题：它支撑哪条支撑结果？支撑是直接的还是间接的？直接支撑指该条目完成后，对应支撑结果的可验证指标会发生变化；间接支撑指它为后续工作打基础，本迭代内看不到结果。初筛以直接支撑为主，间接支撑条目单独列出，由团队决定是否占用本迭代容量。
剔除与暂缓。与所有支撑结果无关的条目，从本轮候选中剔除，回到产品待办并注明原因；依赖外部条件、本迭代无法验证的条目暂缓，标注等待的条件和预计可评估时间。剔除和暂缓都要留下记录，避免下次规划会重复讨论同一批条目。
处理依赖。对保留下来的候选条目，检查条目之间的先后关系，以及对外部系统、数据、其他团队的依赖。存在前置依赖的条目，要么把前置工作一并纳入候选，要么调整顺序或暂缓。依赖处理不充分是迭代中途阻塞的常见原因，这一步应在会上明确到具体条目。
输出候选清单。最终输出一份候选条目清单，每条包含：条目名称、对应支撑结果、入选理由（一句话）、初步规模判断、已知依赖。清单按支撑度排序，容量允许时优先纳入排序靠前的条目。清单是规划会的讨论底稿，不是最终结论，会上仍需团队确认颗粒度和估算。
在条目数量较多、需要多人同时整理时，可以把候选清单放在ONES的迭代工作项中维护，让产品负责人、开发人员在同一份清单上补充理由和依赖，减少会前反复传阅文档的成本。
把入选条目拆到可执行粒度
候选条目通常还是需求层面的描述，直接进入开发会出现理解偏差和估算失真。拆解的目标是让每条工作项满足三个条件：团队内对“做完是什么样”有共识、能在迭代周期内完成、能独立验证。
拆解到迭代内可完成的工作项。按交付路径拆，而不是按工种拆。一个用户可见的功能，可以拆成“数据准备与接口”“页面与交互”“异常处理与提示”“验证与回归”等可独立推进的部分；纯技术条目则按可验证的中间结果拆。拆完后逐条检查：单条工作项是否明显超过迭代周期的一半？如果超过，继续拆；如果拆到无法独立验证，说明拆法有问题，回到按交付路径重新划分。
补齐验收标准、负责人与估算。每条工作项需要写清验收标准，标准要可检查，例如“某操作在指定条件下返回预期结果，异常输入有明确提示”，避免“功能正常”这类无法验证的表述。负责人按工作项指定到人，而不是指定到小组；估算由实际执行者参与给出，单位在团队内统一。估算明显偏离历史水平的条目，要在会上说明原因。
标注依赖与风险，排出执行顺序。在工作项上标注前置依赖、外部依赖和主要风险，风险要写清触发条件和应对方式。执行顺序遵循三条原则：有外部依赖的先启动或先确认；被其他工作项依赖的先做；验证成本高的尽早安排，留出返工时间。顺序不必精确到天，但要能看出哪些工作项可以并行、哪些必须串行。
拆解完成后，Sprint Backlog 应呈现为一份带负责人、估算、验收标准和顺序的工作项列表。此时再整体核对一次容量：所有工作项估算之和与团队可用容量对比，超出部分退回候选清单，不靠压缩估算来“装下”。
角色分工与各环节交付物
条目选择的质量取决于三类角色是否各司其职。职责不清时，常见结果是产品负责人单方面定清单，开发团队会上才第一次看到条目，估算和拆解都被压缩，Sprint Backlog 看似完整、执行中却频繁变更。
| 角色 | 规划会前 | 规划会中 | 规划会后 |
|---|---|---|---|
| 产品负责人 | 维护产品待办优先级；写出迭代目标与支撑结果；完成候选条目初筛并附入选理由 | 解释目标与条目背景；对筛选口径的争议做决定；确认范围取舍 | 把范围变更请求带回待办评估；同步目标相关的外部信息 |
| Scrum Master | 确认容量数据；准备筛选口径表与候选清单模板；检查依赖是否已暴露 | 主持筛选与拆解顺序；记录未决问题；保障团队充分讨论估算 | 跟踪阻塞与依赖的解除；在站会中检查粒度是否仍可执行 |
| 开发团队 | 提前阅读候选条目；对不清楚的条目提出疑问；准备技术依赖信息 | 参与拆解与估算；确认验收标准可验证；认领工作项 | 执行中及时暴露偏差；对无法在迭代内完成的工作项提出重新评估 |
交付物的交接关系是：产品负责人的目标陈述与候选清单交给团队，团队在会中产出拆解后的工作项、估算和执行顺序，Scrum Master 汇总为最终的 Sprint Backlog 并记录未决事项。条目在会中发生变更时，由提出方说明原因，产品负责人确认是否影响目标，团队重新评估规模，变更结果当场记入清单，避免会后口头传达造成版本不一致。
示例：一次迭代的条目选择过程
以下为演示情景，用于说明前述步骤如何衔接，数据为示例设定。
某内部工具团队的两周迭代，产品负责人把目标写成：“审批发起人能在提交前看到必填项缺失提示，因缺项被退回的单据数量在本迭代验证下降。”支撑结果拆为两条：一是提交环节能拦截缺项，二是退回原因对发起人可见。
产品待办中的候选条目包括：表单必填项校验、退回原因展示、审批流节点配置界面改版、历史单据批量导出、移动端适配。按筛选口径逐条判断：前两条直接支撑两条支撑结果，入选；节点配置界面改版属于间接支撑，本迭代看不到结果，暂缓；批量导出与目标无关，剔除并注明原因；移动端适配依赖设计资源，外部依赖未确认，暂缓并标注等待条件。
拆解阶段，表单必填项校验拆为“校验规则配置”“提交时拦截与提示”“异常场景验证”三条工作项，验收标准写明缺项时的提示内容和提交行为；退回原因展示拆为“退回原因字段落库”“发起人页面展示”两条，其中字段落库依赖数据表变更，排在前面。估算合计接近团队容量上限，团队决定把“异常场景验证”的范围缩小到主要路径，其余场景留到后续迭代。
最终 Sprint Backlog 包含五条工作项，按依赖顺序排列：退回原因字段落库、校验规则配置、提交时拦截与提示、发起人页面展示、主要路径异常验证。每条有负责人、估算和验收标准，暂缓与剔除条目连同原因记录在产品待办中。
规划会后保持可执行粒度与完成检查
Sprint Backlog 在规划会结束时成立，执行中仍会变化。保持可执行粒度的做法是把检查嵌入日常节奏，而不是等到迭代结束才发现条目无法完成。
每日站会中的粒度检查。站会除同步进展外，关注两类信号：某条工作项连续两天没有实质推进，可能是颗粒度太粗或存在未暴露的依赖；某条工作项的实际工作量明显超出估算，需要当场判断是拆分还是调整范围。发现问题的处理方式是当天在清单上更新状态和说明，涉及范围调整的提交产品负责人确认。
中途调整时的确认方式。迭代内新增条目或替换条目，需要说明它对应哪条支撑结果、替换掉哪条工作项、容量如何平衡。未经确认的插入会让容量失控，因此调整结果要记入清单，并在下一次站会向团队同步。
未完成条目的重新评估。迭代结束时未完成的工作项，回到产品待办重新评估，不默认结转到下一迭代。重新评估时回答三个问题：未完成的原因是估算偏差、依赖阻塞还是范围变化？剩余工作是否仍支撑下一迭代的目标？拆分方式是否需要调整？评估结论决定它是进入下一轮候选、继续拆分还是暂缓。
完成检查可按以下清单逐项核对：
- 迭代目标是一句可验证的结果陈述，包含对象、变化和判断依据。
- 每条入选条目都能指出对应的支撑结果，并有一句入选理由。
- 剔除与暂缓条目已记录原因和等待条件。
- 每条工作项有负责人、估算和可检查的验收标准。
- 依赖与风险已标注，执行顺序能看出串行与并行关系。
- 工作项估算之和与团队可用容量匹配，超出部分已退回。
- 会中变更已当场记录，清单版本与团队认知一致。
- 未完成条目已重新评估，未默认结转。
以上检查项全部通过，Sprint Backlog 才算达到可执行状态。条目清单、状态和变更记录在ONES的迭代工作项中持续维护时，站会检查与迭代结束的重新评估可以直接基于同一份数据完成，减少清单与实际情况脱节。
常见问题
迭代目标写得太笼统，规划会上条目争论不休，怎么补救？
可以在规划会开场先花十分钟把目标改写成可验证的结果陈述：明确对象（哪个用户、哪个环节）、变化（期望发生什么改变）和判断依据（用什么数据或现象确认达成）。改写后拆成2–4条支撑结果，再让每条候选条目对应到具体支撑结果。如果目标一时无法拆出支撑结果，说明本轮迭代范围可能过大，考虑缩小范围比在会上逐条争论更有效。
团队容量数据不全时，还能按这套方法筛选条目吗？
可以筛选，但容量核对这一步需要补上。容量包括本迭代可用人力、已有承诺占用的时间以及休假和支援安排。数据不全时，先按支撑度排出候选清单，同时把容量缺口标注为待确认事项，在规划会上由团队补充后再核对估算之和。缺少容量数据直接定稿，容易选出超出团队承受范围的条目，执行中再压缩范围的成本更高。
间接支撑目标的条目，比如为后续迭代打基础的技术改造，要不要放进本轮Sprint Backlog？
初筛以直接支撑为主，间接支撑条目单独列出，由团队结合容量决定是否纳入。判断时可以问：这条工作完成后，本迭代内能否看到对应支撑结果的指标变化？如果看不到，它更适合作为技术储备留在产品待办，或拆出一个本迭代内可验证的中间结果再纳入。纳入时要在清单上写明它支撑的是哪条支撑结果，避免变成无归属的“顺手做”。
迭代中途发现某条工作项做不完，应该拆分还是直接移到下一迭代？
先判断原因再决定处理方式。如果是颗粒度太粗，当天在清单上拆分并更新状态；如果是依赖阻塞，明确阻塞方和解除时间；如果是范围变化，提交产品负责人确认是否影响迭代目标。确实无法在本迭代完成的部分，迭代结束时回到产品待办重新评估，回答估算偏差、依赖阻塞还是范围变化，以及剩余工作是否仍支撑下一迭代目标，不默认结转。
用ONES承载Sprint Backlog时，哪些环节最适合放进系统里？
条目整理与状态跟踪环节比较适合。规划会前可以把候选清单放在ONES的迭代工作项中，让产品负责人、开发人员在同一份清单上补充入选理由和依赖；会中拆解出的工作项连同负责人、估算、验收标准一起维护；会后站会检查和迭代结束的重新评估基于同一份数据完成，减少清单与实际执行脱节。方法本身不依赖特定工具，系统的作用是让清单版本和变更记录保持同步。
