Sprint Backlog 是当前迭代内团队承诺完成的工作集合，通常包括迭代目标、从产品 Backlog 选入的待办项、支撑完成的拆解任务，以及团队对范围与完成标准的说明。它只覆盖本迭代，随进展更新，既不是完整的产品需求池，也不等同于迭代计划。下面按组成、边界、形成与更新、相邻概念和示例逐项说明。
要点总览（TL;DR）
- Sprint Backlog 是团队为本迭代选定的工作承诺集合，只覆盖当前迭代，随进展更新。
- 典型内容包括迭代目标、从产品 Backlog 选入的待办项、拆解出的任务、完成标准或验收条件，以及范围与容量说明。
- 产品 Backlog、迭代计划、发布计划以及未进入本迭代的需求都不属于 Sprint Backlog；未完成工作需重新评估后再决定是否纳入下一迭代。
- 它从迭代规划会上选入待办项开始，经拆解估算、每日跟进剩余工作，到范围调整时重新评估，形成一条可跟踪的更新链路。
- 把 Sprint Backlog 当成需求池、纯任务清单或固定不变的合同，会导致承诺被稀释、验收返工和风险后置。
Sprint Backlog 到底指什么
Sprint Backlog 的中文常译为“迭代待办列表”或“冲刺待办列表”，英文术语由 Sprint（迭代/冲刺）和 Backlog（待办列表）组成。它回答两个问题：这个迭代团队要交付什么，以及团队打算怎样推进到完成。用一句话概括：Sprint Backlog 是团队为本迭代选定的工作承诺集合，包含目标、待办项和支撑任务，并在迭代过程中持续更新。
理解这个定义要抓住“当前迭代”这个限定。产品 Backlog 覆盖产品的长期需求，Sprint Backlog 只截取其中本次迭代要做的部分。它也不是一份静态文档，而是团队每天据此跟进剩余工作、调整做法的依据。迭代目标给出方向，Sprint Backlog 承载实现该目标的具体工作项，迭代计划则是团队商定这些内容的活动与安排。
Sprint Backlog 包括哪些内容
不同团队记录 Sprint Backlog 的载体不同，可能是一块看板、一张任务列表或工具中的迭代视图，但典型内容组成相对稳定。可以对照下面这份清单检查自己团队的迭代清单是否完整。
- 迭代目标：用一两句话说明本迭代要达成的业务或用户价值，为选入的待办项提供取舍依据。
- 从产品 Backlog 选入的待办项：本迭代承诺完成的需求、用户故事或缺陷修复项，每项应有明确描述和优先级来源。
- 为完成待办项拆解出的任务：设计、开发、测试等角色把待办项拆成可执行、可跟踪的子任务，并标注负责人。
- 完成标准或验收条件：说明待办项做到什么程度算完成，例如验收标准、测试通过条件、上线检查项。
- 范围与容量说明：记录本迭代纳入的工作范围，以及团队可投入的容量依据，如人数、可用工时或故事点总量，帮助判断承诺是否合理。
这五项中，迭代目标和完成标准最容易被省略。缺少目标，待办项容易变成按优先级堆叠的任务；缺少完成标准，团队对“做完”的理解不一致，验收阶段容易反复。范围与容量说明则让后续调整有参照，避免迭代中途随意加塞。
哪些内容不属于 Sprint Backlog
Sprint Backlog 的边界由“本迭代是否承诺完成”划定。以下内容常被误放进来，需要区分清楚。
- 完整的产品 Backlog：产品 Backlog 是需求的全景池，包含尚未排期、优先级较低或未来才做的条目。只有被选入本迭代的部分才进入 Sprint Backlog。
- 迭代计划本身：迭代计划是规划会议上的活动与安排，包括时间、参与角色、讨论议程和商定的结果。Sprint Backlog 是规划产出的工作项集合，两者是活动与产物的关系。
- 未进入本迭代的需求：即使某项需求很重要，只要本次没有选入并承诺，它仍留在产品 Backlog 中，不默认属于本迭代。
- 发布计划与路线图：它们描述多个迭代或更长周期的交付安排，时间跨度和颗粒度都大于 Sprint Backlog。
- 未完成工作的自动结转：迭代结束时未完成的事项需要重新评估优先级、剩余工作量和必要性，再决定是否纳入下一迭代，不默认原样顺延。
把产品 Backlog 整体搬进迭代视图，会让团队看不清本迭代真正的承诺范围；把迭代计划文档当作 Sprint Backlog，则会让工作项缺少可跟踪的状态。边界清晰，后续的进度判断才有可靠基础。
Sprint Backlog 如何形成并随迭代更新
Sprint Backlog 的生命周期从迭代规划开始，到迭代结束收尾，中间经历拆解、跟进和范围调整几个环节。
- 规划会上选入待办项：产品负责人按优先级从产品 Backlog 中提出候选需求，团队共同评审，确认本迭代要完成的需求与验收标准。这一步确定的是“做什么”。
- 拆解任务并估算：设计、研发、测试人员就达成一致的待办项拆出子任务，估算工作量并分配负责人，形成可执行的推进路径。这一步确定的是“怎么做”。
- 每日跟进剩余工作：团队成员围绕待办项完成自己拆解的任务，通过看板更新任务状态，在每日站会上对齐进度与风险，并据此更新剩余工作量。
- 范围调整时重新评估：迭代中途出现新增需求或阻塞时，团队需要评估对迭代目标的影响，明确哪些工作移出、哪些保留，并同步调整范围说明，避免承诺与实际脱节。
这条流程的关键在于“更新”有依据：状态变化来自实际完成情况，范围变化来自团队评估，而不是随时改清单。以 ONES 为例，产品负责人可以按优先级将产品待办列表中的需求规划至对应迭代，在迭代计划会议上与团队评审；需求与验收标准达成一致后，设计、研发、测试人员可用子任务拆分需求，迭代中通过敏捷看板管理任务状态，并在每日站会借助看板对齐进度与风险、通过燃尽图观察剩余工作趋势。这套组织方式对应的是上述流程中的选入、拆解和跟进环节。
与相邻概念的区别
Sprint Backlog、产品 Backlog、迭代目标和迭代计划经常被混用。它们回答的问题、时间跨度和责任主体各不相同，用一张表对照更清楚。
| 概念 | 回答的问题 | 时间跨度 | 主要责任主体 |
|---|---|---|---|
| Sprint Backlog | 本迭代团队承诺交付什么、怎样推进 | 一个迭代 | 开发团队整体维护和更新 |
| 产品 Backlog | 产品接下来需要做哪些需求，优先级如何 | 长期、持续演进 | 产品负责人负责排序与维护 |
| 迭代目标 | 本迭代要达成什么价值，作为取舍依据 | 一个迭代 | 团队与产品负责人共同商定 |
| 迭代计划 | 用什么活动、什么安排确定本迭代工作 | 规划会议及配套安排 | 团队共同参与，产品负责人提供需求输入 |
从表中可以看出，产品 Backlog 是来源，Sprint Backlog 是本迭代的截取与细化；迭代目标是 Sprint Backlog 的方向约束，迭代计划是产生 Sprint Backlog 的活动过程。四者配合使用，任何一项缺失都会影响迭代的可控性。
具体例子与常见误解
以下为一个演示情景，用于说明 Sprint Backlog 的典型构成，不代表真实项目数据。某团队本迭代的目标是“让新用户完成首次下单的流程可用”。据此形成的 Sprint Backlog 包括：迭代目标一句；从产品 Backlog 选入的三项待办——下单页改版、支付失败提示优化、订单状态查询接口；每项待办下拆出的设计、开发、联调、测试子任务及负责人；每项待办的验收条件，例如支付失败提示需覆盖三种常见失败原因；以及本迭代的范围与容量说明，注明团队可用人力和已承诺的故事点总量。迭代进行中，团队每天更新任务状态，某项接口因外部依赖延迟时，经评估将联调任务移出本迭代并记录原因。
围绕这个例子，有三种常见误解值得纠正。
- 把 Sprint Backlog 当成需求池：将所有待做需求都放进来，导致本迭代承诺被稀释。纠正方式是只保留本迭代承诺完成的部分，其余留在产品 Backlog。
- 把它当成单纯的任务清单：只列任务不写迭代目标和完成标准，团队容易陷入“做完任务但没交付价值”。纠正方式是补齐目标与验收条件，让任务服务于目标。
- 把它当成固定不变的合同：认为一旦确定就不能调整，遇到阻塞仍硬扛。纠正方式是承认范围可以经团队评估后调整，但调整要有记录、有依据，并与迭代目标对齐。
这三种误解带来的实际影响分别是：迭代结束时交付不完整却说不清原因、验收阶段反复返工、以及风险被拖延到迭代末期才暴露。把 Sprint Backlog 当作一份随进展更新、边界清晰的工作承诺，团队在每日跟进和迭代评审时才有可靠的判断依据。
常见问题
Sprint Backlog 一旦确定，迭代中途还能调整吗？
可以调整，前提是经过团队评估并记录依据。迭代中途出现新增需求、外部依赖延迟或阻塞时，团队需要判断这些变化对迭代目标的影响，明确哪些工作移出、哪些保留，并同步更新范围说明。调整的依据来自实际完成情况和团队评估，调整后仍要与迭代目标对齐。把清单当成完全不可变，遇到阻塞硬扛，风险往往拖到迭代末期才暴露。
迭代结束时没做完的工作，会自动进入下一个迭代吗？
不默认自动结转。未完成事项需要重新评估优先级、剩余工作量和必要性，再决定是否纳入下一迭代。原因是迭代结束时产品优先级可能已经变化，原样顺延会让下一迭代的承诺范围被动膨胀。团队可以在迭代评审或回顾时逐项确认，把仍然必要的工作重新排入产品 Backlog，再参与下一轮规划。
Sprint Backlog 和迭代计划是什么关系？
迭代计划是规划会议上的活动与安排，包括时间、参与角色、讨论议程和商定的结果；Sprint Backlog 是这些活动产出的工作项集合。前者是过程，后者是产物。把迭代计划文档直接当作 Sprint Backlog，工作项会缺少可跟踪的状态和负责人，每日跟进时难以判断真实进度。
团队规模较小、角色划分不细时，Sprint Backlog 的内容可以简化吗？
可以按实际协作方式简化记录形式，但迭代目标、选入的待办项和完成标准这三类信息建议保留。人数少的团队可能不需要为每项待办拆出多层子任务，任务粒度可以更粗，负责人也可以由团队共同承担。范围与容量说明同样值得保留，哪怕只用一句话记录本迭代可投入的人力和已承诺工作量，后续判断是否加塞时就有了参照。
在工具中管理 Sprint Backlog，需要关注哪些组织方式？
重点看三件事：需求能否按优先级从产品待办列表规划到对应迭代，待办项能否拆成子任务并分配负责人，迭代中能否通过看板更新任务状态并观察剩余工作趋势。以 ONES 为例，产品负责人可将产品待办列表中的需求规划至对应迭代，与团队评审需求与验收标准后，由设计、研发、测试人员用子任务拆分需求，迭代中通过敏捷看板管理任务状态，并在每日站会借助看板对齐进度与风险、通过燃尽图观察剩余工作趋势。具体视图与字段以实际产品配置为准。
