Sprint Backlog（迭代待办列表）是团队为当前这一个 Sprint 选定的工作集合。它通常包括：本迭代要完成的 Product Backlog 条目（多为用户故事）、把每条拆到可执行粒度的任务、任务的工作量或工时估算、任务负责人与状态，以及团队为实现迭代目标所需的交付约定，如完成标准、依赖与风险。它由开发团队在 Sprint Planning 中共同确定，只覆盖当前迭代，随进展每日更新；未完成的工作在迭代结束时重新评估，不默认自动结转到下一个 Sprint。
要点总览（TL;DR）
- Sprint Backlog（迭代待办列表）是团队为当前这一个 Sprint 选定的工作集合，在 Sprint Planning 中围绕迭代目标共同确定，只覆盖当前迭代。
- 内容通常包括：选入本迭代的产品待办条目、拆解后的任务、估算与负责人、完成标准与验收条件，以及依赖、风险和任务状态与剩余工作量。
- 它与产品待办分工明确：未选入本迭代的条目留在产品待办中按优先级排序，版本计划、团队制度与会议纪要也不属于迭代待办。
- 迭代进行中，团队在每日站会更新任务状态与剩余工作量；范围调整需团队协商并保持迭代目标可达成。
- 迭代结束时未完成条目重新评估去向，不默认自动结转到下一个 Sprint；收尾时检查待办与迭代目标的一致性。
Sprint Backlog到底是什么
Sprint Backlog 的中文常译为“迭代待办列表”或“冲刺待办列表”，是 Scrum 框架中团队针对当前一个 Sprint 所使用的工作清单。它回答两个问题：这个迭代团队承诺交付什么，以及团队打算怎样把这些工作做出来。前者对应从产品待办中选入的条目，后者对应团队自己拆解出的任务和实现路径。
这份清单产生于 Sprint Planning（迭代计划会议）。产品负责人带着排好优先级的产品待办参与，开发团队评估工作量与可行性，共同确定本迭代要完成的条目，并围绕 Sprint Goal（迭代目标）形成一致理解。迭代目标是这个 Sprint 的方向性承诺，Sprint Backlog 则是承载该目标的具体工作集合；目标决定选什么、拆什么，待办列表则让目标落到可执行的任务上。
用一句话概括其内容构成：Sprint Backlog 由本迭代选入的需求条目、拆解后的任务、估算与负责人、完成标准与验收条件，以及依赖、风险和状态信息组成。它属于开发团队的工作工具，团队对其内容有自主管理权，外部可以提出调整建议，但具体怎么拆、怎么排由团队决定。
一份Sprint Backlog通常包含哪些内容
检查一份迭代待办是否完整，可以逐项对照下面的内容。不同团队在字段命名和颗粒度上会有差异，但核心信息项大体一致。
- 选入本迭代的产品待办条目。通常是用户故事或需求项，写明“谁、要什么、为什么”。这一层回答“这个迭代交付什么价值”，是后续拆解任务的依据。常见写法是保留故事标题与简要描述，并关联到产品待办中的原始条目。
- 拆解后的任务。把每条需求拆成可执行、可分配、可判断完成的工作单元，例如“设计接口字段”“编写单元测试”“联调支付回调”。任务粒度以“一个人在一两天内能完成”为常见参考，过粗难以跟踪，过细则增加管理成本。
- 估算与负责人。估算可以用故事点衡量相对规模，也可以用工时估算任务持续时间。负责人明确谁来做，避免任务悬空。估算的作用是帮助团队判断本迭代容量是否匹配，它反映的是团队对工作量的判断，不等同于对外承诺的交付日期。
- 完成标准与验收条件。完成标准（Definition of Done）是团队对“做完”的统一约定，例如代码评审通过、测试用例覆盖、文档更新；验收条件则针对具体需求，写明产品负责人验收时检查什么。两者共同减少“做完了但不算完成”的争议。
- 依赖、风险与备注。记录本迭代内外部依赖（如等待第三方接口、依赖其他团队交付）和已识别风险，以及必要的背景说明。这些信息让站会讨论有据可依，也便于提前协调。
- 任务状态与剩余工作量。状态反映任务处于待办、进行中还是已完成；剩余工作量用于判断迭代进度是否偏离预期。两者结合，团队才能在看板或燃尽图上看到真实进展。
哪些东西不属于Sprint Backlog
Sprint Backlog 与 Product Backlog（产品待办列表）分工不同。产品待办是全部已知需求的排序清单，由产品负责人维护，覆盖多个迭代甚至更长时间；Sprint Backlog 只取其中本迭代要做的部分。未选入本迭代的条目继续留在产品待办中，按优先级等待后续规划，不需要搬进迭代待办。
版本计划或路线图描述的是跨迭代的交付安排，回答“几个迭代之后发布什么”，它属于规划层面的信息，不构成某个迭代的待办内容。团队长期制度、会议纪要、值班安排等文档也不属于迭代待办，它们可以放在团队知识库中，但与“本迭代做什么、怎么做”不是同一类信息。
| 信息项 | 归属 | 判断依据 |
|---|---|---|
| 本迭代选入的用户故事 | Sprint Backlog | 已承诺在当前迭代完成 |
| 尚未排入迭代的需求 | Product Backlog | 仍在产品待办中按优先级排序 |
| 拆解后的开发、测试任务 | Sprint Backlog | 直接支撑本迭代条目完成 |
| 未来两三个版本的发布计划 | 版本计划/路线图 | 跨迭代的规划信息 |
| 团队编码规范、会议纪要 | 团队知识库 | 长期制度或过程记录，非迭代工作项 |
迭代进行中Sprint Backlog如何变化
Sprint Backlog 是一份活的工作清单。每日站会中，团队成员对照任务更新状态和剩余工作量：昨天完成了什么、今天计划做什么、遇到什么阻碍。更新动作本身很轻，但它是团队判断进度、识别风险的依据。剩余工作量持续累加后，团队能看出本迭代是否还能按计划完成。
范围调整需要团队协商。常见情形包括：发现某条需求的工作量远超预估、出现必须优先处理的生产问题、外部依赖延迟导致任务无法推进。此时团队与产品负责人沟通，明确是替换条目、缩小范围还是调整验收条件，并把变更记录在待办中。调整的前提是保持迭代目标仍然可达成；如果目标本身需要改变，应由产品负责人和团队共同确认。
迭代结束时，未完成的条目需要重新评估，而不是默认自动结转到下一个 Sprint。团队要判断这些条目是否仍然有价值、优先级是否变化、拆分是否合理，再决定放回产品待办、重新排入后续迭代或取消。这个动作让每个迭代的承诺边界清晰，也避免未完成工作无声地滚入下一轮。收尾时还应检查 Sprint Backlog 与迭代目标的一致性：已完成的工作是否真正支撑了目标，未完成部分对目标的影响是什么。
一个具体例子与常见误解
假设一个为期两周的迭代，迭代目标是“让新用户完成注册后能收到欢迎邮件并进入引导页”。一份可用的 Sprint Backlog 大致如下：选入两条用户故事——“新用户注册后触发欢迎邮件”和“注册成功后跳转引导页”；第一条拆成“配置邮件模板”“编写发送逻辑”“补充发送失败重试”“编写集成测试”四个任务，第二条拆成“设计引导页跳转规则”“实现跳转逻辑”“补充埋点”三个任务；每条任务标注负责人和估算，两条故事分别写明验收条件，例如“邮件在注册成功后一分钟内送达”“跳转失败时展示提示并记录日志”；备注中记录依赖邮件服务商沙箱环境这一外部条件。迭代进行中，团队每天更新任务状态，发现邮件服务商环境延迟时，及时与产品负责人协商调整测试安排。
常见误解有三类。第一类是把整个产品待办当成迭代待办，把所有需求都列进来，结果迭代范围失控、优先级失去意义；纠正方式是只保留本迭代承诺的条目，其余留在产品待办中排序。第二类是只写任务不写验收条件，团队按自己的理解完成开发，验收时才发现与产品负责人预期不符；纠正方式是在计划阶段就把验收条件写清楚，并与完成标准一起作为任务完成的判断依据。第三类是把估算当成对外承诺，把故事点或工时直接换算成交付日期对外发布；估算的作用是团队内部判断容量，对外承诺应结合迭代目标和实际进展沟通，避免因估算偏差造成信任损耗。
用工作项承载Sprint Backlog时的管理衔接
把上述内容落到工具中，通常形成两级工作项：需求条目作为上层工作项，任务或子任务作为下层工作项。以 ONES 为例，产品负责人可以根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；团队对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可以利用子任务将需求拆分，便于后续处理和跟踪。这一流程对应了“选入条目—拆解任务”两个动作。
迭代目标、完成标准与状态信息需要有明确的记录位置。ONES Project 支持编写需求、自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；任务工时统计可用于估算任务持续时间，看板、燃尽图等工具用于实时查看进度。团队在每日站会中借助敏捷看板对齐迭代进度与风险，任务状态的更新就发生在这一环节。
迭代结束时的交接同样需要落到动作上：团队围绕已完成需求进行评审，对未完成条目重新评估后决定去向；迭代完成并发布后，可以召开迭代回顾会，通过燃尽图、工时日志等数据报表复盘进度、质量和成本偏差。这样，Sprint Backlog 从计划输入、团队拆解与执行、状态更新，到评审与回顾，形成一条可追溯的管理链路。
常见问题
迭代进行到一半，产品负责人临时要求加入一条高优先级需求，应该怎么处理？
先判断这条需求与当前迭代目标的关系，再由团队评估工作量与影响，而不是直接插入待办列表。常见做法有三种：一是替换掉一条价值较低、尚未开始的条目，保持迭代总容量不变；二是缩小某条需求的验收范围，腾出工作量；三是确认当前迭代无法容纳，将其放回产品待办并排到后续迭代。
无论选哪种，都需要团队与产品负责人共同确认，并把变更记录在迭代待办中。如果新增需求会改变迭代目标本身，应由产品负责人和团队一起重新确认目标，避免目标与实际工作脱节。
迭代结束时没做完的条目，可以直接带到下一个 Sprint 吗？
不建议默认结转。未完成条目在迭代结束时需要重新评估：它是否仍然有价值、优先级是否发生变化、原来的拆分是否合理、估算偏差出在哪里。评估之后再决定是放回产品待办重新排序、拆小后放入后续迭代，还是取消。
直接结转容易让未完成工作无声地累积，也会模糊每个迭代的承诺边界。重新评估这个动作本身，还能为迭代回顾提供素材，帮助团队改进估算与拆分方式。
团队规模较小、需求变化频繁时，Sprint Backlog 还需要写得这么细吗？
内容项可以按实际情况裁剪，但几个关键信息建议保留：本迭代选入的条目、可执行的任务、负责人，以及验收条件。团队人数少时，任务粒度可以略粗，估算方式也可以简化，只要团队内部对工作量判断有共识即可。
需求变化频繁的场景下，更重要的是保持迭代目标稳定，并让变更走协商流程。待办列表写得过细会带来维护成本，写得过粗则难以跟踪进度，团队可以在几个迭代后根据实际情况调整颗粒度。
Sprint Backlog 里的估算，能不能直接作为对外的交付承诺？
估算反映的是团队对工作量的判断，用于内部判断本迭代容量是否匹配，它本身不构成对外承诺。把故事点或工时直接换算成交付日期对外发布，一旦出现偏差，容易造成信任损耗。
对外沟通交付预期时，可以结合迭代目标、已完成进展和已识别风险来说明，并保留调整空间。团队内部则可以用估算与实际工时的对比，持续校准判断的准确度。
用工具承载迭代待办时，需求条目和任务应该分成几级工作项？
常见做法是两级：需求条目作为上层工作项，任务或子任务作为下层工作项。上层回答“这个迭代交付什么”，下层回答“具体怎么做、谁来做”。以 ONES 为例，产品负责人可以根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；团队对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可以利用子任务将需求拆分，便于后续处理和跟踪。
层级不必追求更多，关键是需求与任务之间的对应关系清晰，状态更新能反映真实进展。迭代完成并发布后，可以召开迭代回顾会，通过燃尽图、工时日志等数据报表复盘进度、质量和成本偏差。
