Product Backlog是从用户的角度来描述需求，而Sprint Backlog是从敏捷团队的角度来细分需求，即从技术实施层面讨论用户故事应该如何实现。简言之，Product Backlog告诉敏捷团队产品需要做成什么样子，描绘了一个虚拟的产品雏形；而Sprint Backlog告诉敏捷团队为了实现该用户故事，应该如何去实施，讨论的是“怎么做”的问题。
Product Backlog中用户故事被划分为若干迭代任务，每个迭代任务都会在上个迭代版本的基础上做增量开发，直到所有的迭代任务全部实施完成。
Sprint Backlog是基于经验采用头脑风暴的方法分解得到的任务列表，既是Scrum团队成员进行任务认领的基本单位，也是后续进行任务复盘的基本单位。Sprint Backlog可以采用Excel、看板或者敏捷的项目管理工具进行维护。Scrum Backlog可以理解为传统项目管理中的WBS（Work Breakdown Structure），是典型的采用面向交付物的任务分解方法得到的WBS。
仍以音乐播放器为例，现将Product Backlog需求进行二次分解，获得Sprint Backlog，如表3-7所示，表中仅列出了Product Backlog No．1对应的Srpint Backlog，仅供参考。
表3-7 Product Backlog再次分解为Sprint Backlog
续表
表3-7其实是不完整的，因为Sprint Backlog虽然完成了对Product Backlog进行细化分解，但是未给出每个Sprint Backlog的预估工作量。预估工作量是由Scrum团队自己估算的，Sprint Backlog工作量合计应该不超过Product Backlog估算的工作量。如果任务拆分后发现Sprint Backlog工作量合计远大于Product Backlog估算的工作量，则需要对Product Backlog的工作量估算值进行修订和完善。
综上所述，Sprint Backlog是Scrum团队在当前Sprint必须完成的任务清单。根据Sprint Backlog，Scrum团队在Sprint的最后交付一个带有增量功能的软件。创建Sprint Backlog发生在Sprint计划会议的第二部分，每一个团队成员都需要参加。真正重视这个过程可以更好地了解Sprint中团队应做哪些工作，这是更好地制订Sprint计划的基础。尽管如此，许多团队仍然不重视这个事情。以下这些建议可能对他们有所帮助：
（1）让每个队员都要参与这个过程。
（2）确定开发任务之前，讨论每一个用户故事应该如何实现。
（3）对于完成的标准要有明确的定义。
（4）标识出所有需要完成的任务。
（5）不要事先分配任务。(www.xing528.com)
（6）重新审视Sprint的承诺。
（7）不要使用过多的时间。
（8）在Sprint过程中演化Sprint Backlog。
什么是WBS
WBS（Work Breakdown Structure）即工作分解结构，就是把一个项目按一定的原则分解成一个个子项目，子项目再分解成一个个子任务，子任务再分解成一项项工作包，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。WBS是对工作由粗到细的分解过程，可以把项目分解到相对独立、内容单一、易于进行成本核算和检查的工作单元。WBS工作任务分解示意图如图3-9所示。
图3-9 WBS工作任务分解示意图
WBS处于计划过程的中心，是制订进度计划、资源需求、成本预算、风险管理计划、采购计划和控制项目变更等的重要基础。
WBS的主要用途：
（1）WBS是一个描述思路的规划和设计的工具，能帮助项目经理和项目团队确定并有效地管理项目。
（2）WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。
（3）WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。
（4）WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
