产品backlog由所有的功能特性，包括业务功能，非业务功能（技术、架构和工程实践相关），提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。
一个完整的backlog是一个的蓝图，可以根据它来把产品改造成为我们期望的样子。 但是在Scrum中，Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的，我们会持续的改变它去确保我们的产品是最合理的，最有竞争力的，最有价值的。
当我们去看产品的backlog的时候，优先级是一个重要的视角，优先级越高的backlog需要越清晰，越详细。对于优先级低的backlog，详细程度会越低，直到几乎我们不能认为它是一个backlog项（非常低的优先级，只相当于一个占位符，来用做提醒）。
估算 对每个backlog项做估算（包括成本，复杂度，风险，功能点）。优先级越高的Backlog估算要越精确，在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化（对于那些很重要，并且可以快速解决的问题可以先做）。 我们要经常做估算。
创建者 Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点，销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活，更具扩展性，可复用性，开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。
优先顺序 每个backlog项都有优先级，这些backlog项按照优先次序排行队列放在backlog列表中。在评估的过程中
我需要在“什么样的产品特性，技术架构，缺陷的修复才会给产品公司和它的客户带来带来最大的收益？ ” 和”什么样的技术架构，工程方法使我们可以更快，更高质量的交付版本”之间做出抉择。不论是对内部技术环境或者外部市场，我们都需要不断筛选和评估什么是最重要的。
版本发布 规划接下来的几个版本，包括版本的目标，及可能包含的内容。（我们可能需要在发布内容，开发成本及发布周期之间做出抉择）。
产品Backlog要按照release分组，要让开发团队的所有成员都全部的了解总体开发目标，并且确保所有的技术问题都做了充分的考虑并且放入了产品backlog.
负责人 我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表，对于商业产品的开发， backlog的负责人也许会是产品经理，对于内部项目的开发backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品 backlog的优先级和工作量估算，同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。
优先级 只有一个人来进行排序的工作，这个人的职责是确保达成产品的愿景，提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级，他们必须说服这个负责人去改变。
可视化 产品的backlog需要能够让开发团队，利益相关者等相关的人能够很容易的看到它的内容，状态，进展等等。
