https://www.atlassian.com/agile
一个良好优先级的敏捷backlog不仅使发布和迭代计划更容易，它还传播了你的团队打算花时间做的所有事情——包括客户永远不会注意到的内部工作。这有助于为涉众和其他团队设定期望，特别是当他们为您带来额外的工作时，并使工程时间成为固定资产。
3.5.1 什么是产品待办事项列表?
产品待办事项列表是根据路线图及其需求为开发团队列出的工作的优先级列表。最重要的项目显示在产品待办事项列表的顶部，这样团队就知道首先要交付什么。开发团队没有按照产品负责人的进度完成待办事项列表，产品负责人也没有将工作推给开发团队。相反，开发团队从产品待办事项列表中提取工作，因为产品待办事项列表有足够的容量，可以是持续的(看板)，也可以是迭代的(scrum)。
专家提示:
将所有东西都放在一个问题跟踪器中——不要使用多个系统来跟踪bug、需求和工程工作项。如果这是开发团队的工作，那么将它保存在一个backlog中。
3.5.2 从两个“R”开始
团队的路线图和需求为产品待办事项列表提供了基础。路线图计划可以分解为几个史诗，每个史诗都有几个需求和用户故事。让我们来看看一个名为“太空团队”的虚构产品的路线图。
由于“太空团队”网站是路线图中的第一个项目，我们希望将该项目分解为各个项目(在这里以绿色、蓝色和蓝绿色显示)和每个项目的用户故事。
然后，产品所有者将每个用户描述组织为开发团队的单个列表。产品所有者可以选择首先交付一个完整的史诗(左)。或者，对程序来说，更重要的是测试预订折扣航班，这需要几个史诗故事(右)。参见下面的两个例子。
什么会影响产品所有者的优先级？
- 客户优先级
- 迫切需要反馈
- 相对实施难度
- 工作项之间的共生关系（例如，如果我们首先执行A，则B会更容易）
尽管产品负责人负责对待办事项进行优先级排序，但这并不是凭空完成的。 有效的产品负责人寻求客户，设计师和开发团队的意见和反馈，以优化每个人的工作量和产品交付。
3.5.3 保持待办事项列表的健康
一旦建立了产品待办事项列表，定期维护它以跟上项目的进度是很重要的。产品负责人应该在每次迭代计划会议之前检查backlog，以确保优先级是正确的，并且从上次迭代中得到的反馈已经被合并进来了。在敏捷的圈子里，对backlog的定期检查通常被称为“backlog梳理”(有些人使用术语backlog细分)。
一旦待办事项列表变大，产品所有者就需要将待办事项列表分为近期和长期项目。 近期项目需要充分充实后才能贴上标签。 这意味着已经草拟了完整的用户案例，已经选出了与设计和开发的协作，并且已经对开发进行了估算。 长期项目可能仍然含糊不清，尽管从开发团队获得粗略估计以帮助确定优先级是一个好主意。 这里的关键词是“粗糙”：一旦团队完全理解并开始处理这些长期项目，估计值就会改变。
backlog充当产品所有者和开发团队之间的连接。产品所有者可以在任何时候根据客户反馈、细化评估和新需求对backlog中的工作重新划分优先级。但是，一旦工作在进行中，将变更保持在最低限度，因为它们会扰乱开发团队，影响焦点、流程和士气。
专家提示:
一旦backlog超出了团队的长期能力，就可以解决团队永远无法解决的问题。在团队的问题跟踪器中，用一个特定的解决方案标记这些问题，比如“超出范围”，以供以后的研究使用。
要注意的反模式
- 产品负责人在项目开始时对backlog进行优先级排序，但是当来自开发人员和涉众的反馈不断涌来时，他不会对backlog进行调整。
- 团队将backlog上的条目限制为那些面向客户的条目。
- 待办事项列表以文档的形式保存在本地，并且不经常共享，防止相关方获得更新。
3.5.4 产品待办事列表如何保持团队的敏捷性?
精明的产品所有者严格地修饰他们的程序的产品待办事项列表，使之成为项目工作项的可靠且可共享的大纲。
产品待办事列表会引发争论和选择，从而保持项目的健康——并非所有事情都可以优先考虑。