译者导读：

本文是对 Scrum 中“Sprint Backlog”（Sprint待办列表）这一核心概念的详细阐述。原文深入探讨了其在 Sprint 计划、每日站会、进度跟踪及团队自组织中的关键作用，并强调了其作为动态工作计划和团队承诺的重要性。

在翻译过程中，我们尽量保留了原文的专业术语和严谨表述，力求准确传达 Scrum 框架的精髓。

希望本文能为国内敏捷实践者、Scrum 团队成员及相关管理者提供清晰的指引，帮助团队更好地利用 Sprint Backlog 这一工具，提升Sprint执行的透明度、可控性和协作效率。
¶7 Scrum团队有已经定义好的¶54 产品待办列表（PB）后，召开¶24 Sprint计划会去定义¶46 当前Sprint。¶14 开发团队需向¶11 产品负责人，就预计交付的¶55 产品待办列表项（PBIs）提供预测，但具体开发计划需由团队成员自行制定。 

为了在Sprint中维护好这一过程，开发团队需要非常清晰地知道为了完成¶71 Sprint目标 所剩余的工作。

为了知道团队是否可以在Sprint中完成产品待办列表项（PBIs），团队就需要理解产品待办列表项（PBIs）的具体细节。把产品待办列表（PBIs）拆分到¶58 更小颗粒度可以帮助团队深刻的理解，为了完成一个PBI，他们到底需要做什么。（参见 ¶82 完成的定义）这一部分工作是Scrum流程里必须的，这类设计工作也会融入 Scrum 框架本身，其中任何一部分都不能省略。但在Sprint的初期  ，团队对所需开展的工作只有不完整不清晰的认知，而随着更深入的理解，工作量也可能会增加。

开发团队需要一个基准来帮助他们以自组织的形式完成Sprint目标。因此在¶29 每日站会中，对剩余的工作提供频繁且准确的反馈，对于开发团队掌控开发动态变得至关重要。

开发团队需要一个起始点来度量他们相对于Sprint目标的进展。当然，¶19 Scrum Master和产品负责人也对此非常感兴趣。但实际上，开发团队才是真正创造¶85 产品增量 的人。

因此：

开发团队需要制定一份工作计划，明确开发团队为实现Sprint目标必须完成的所有工作。开发团队通常会将这些工作细分为¶73 Sprint待办列表项（SBIs）。这些条目可以是开发团队必须完成的任务、组合后构成可交付成果的中间构建模块，或任何其他有助于团队理解如何在Sprint内达成Sprint目标的工作单元。

开发团队负责创建并拥有Sprint待办列表，且只有团队成员共同商议后才能对其进行修改。（参见《敏捷项目管理：使用 Scrum》[Sch01]，第 50 页；另见¶76 开发团队制定的工作计划）。创建Sprint待办列表的核心，在于对产品待办列表项（PBIs）进行详细设计，确保开发团队中的任何人都能清晰解释他们如何实现Sprint目标（参见《30 天交付软件：敏捷管理者如何突破困境、赢得客户并甩开竞争对手》[SS12]）。Sprint待办列表帮助开发团队提供了一种明确 “如何开展开发工作” 的机制，还能帮助开发团队记录其设计决策。根据Sprint的定义，它是有时间盒限制的，即固定时长。因此，开发团队在创建Sprint待办列表时，必须参考自身的速度（Velocity，参见第 320 页 “速度相关说明”），确保列表中的工作在Sprint周期内可完成，从而服务于Sprint目标。借助例如“昨天的天气”（ ¶66 Yesterday’s Weather）和 “更新后速度”（ ¶70 Updated Velocity）等速度测量模式，将有助于团队判断哪些工作可以最终被放入Sprint待办列表中。

一份精准的Sprint待办列表（Sprint Backlog）能帮助开发团队记录所有他们需要完成的具体工作。开发团队需要决定Sprint待办列表（Sprint Backlog）的顺序并且根据顺序去完成，以确保其最大化实现Sprint目标（Sprint Goal）的可能性。Sprint待办列表的内容在Sprint（Sprint）期间可以发生变更：当开发团队对工作难度有了更深入的了解后，可能会新增或修改Sprint待办列表项（SBIs）。团队可以移除Sprint待办项（SBI），也能对它们进行拆分或合并。因为Sprint待办列表（Sprint Backlog）本身是动态变化的，所以在每日站会（Daily Scrum）上，增量式重规划就成了一项主要工作。

Sprint待办列表（Sprint Backlog）为跟踪进度（参见 ¶43 Sprint燃尽图）和可视化状态（参见 ¶78 可视化状态）提供了基础。在每日站会（Daily Scrum）上，它帮助开发团队成员确定接下来要完成的工作。虽然Sprint待办列表没有正式的排序规则，但某种意义上排序还是存在的 —— 因为某些Sprint待办项（SBI）的完成依赖于其他项。开发团队围绕产品待办项（PBI）开展的 “蜂拥式工作”（参见 ¶25 蜂拥工作法：单件流持续交付）也会影响排序方式，但具体如何管理排序还是由开发团队自主决定。

无论如何管理，开发团队都必须清楚Sprint待办项之间的依赖关系，这样才能合理安排工作顺序，并准确掌握项目状态（参见 ¶79 优先处理依赖关系）。开发团队可以通过 ¶56 提到的信息辐射器（例如 ¶44 Scrum 白板），让所有相关方都能清晰了解Sprint待办列表，以此提升其透明度。需要注意的是，开发团队之外的任何人不得利用这种透明度对团队进行微观管理。

ScrumMaster 应时刻留意是否有存在滥用“信息辐射器”的情况。Sprint燃尽图 和 Scrum 看板能把Sprint待办列表的进度，转化成更直观的“信息辐射器”，方便大家快速看懂进度。

译者：雷慧雯

校对：杨光