优先级高的敏捷积压不仅可以简化发布和迭代计划，还可以广而告之团队准备花时间做的所有内容，包括客户永远不会注意到的内部工作。
这有助于与利益相关者和其他团队建立期望，尤其是当他们为您带来更多工作时，并使工程时间成为固定资产。
什么是积压的产品？
产品待办事项列表是从路线图及其要求派生而来的开发团队的优先工作清单。最重要的项目显示在产品积压的顶部，因此团队知道首先交付什么。开发团队不会按照产品所有者的 进度来处理积压的工作 ，并且产品所有者不会将工作推向开发团队。取而代之的是，开发团队会在有能力的情况下从产品待办事项中提取工作，而这些工作可以是连续（看板）或迭代（scrum）。
提示：
将所有内容放在一个问题跟踪器中-不要使用多个系统来跟踪错误，需求和工程工作项。如果对开发团队有用，请将其保存在一个积压中。
路线图和需求
团队的 路线图 和 要求 为产品积压奠定了基础。路线图计划分为几个史诗，每个史诗将有几个要求和用户故事。让我们看一下名为“太空中的团队”的虚拟产品的路线图。
由于“太空团队”网站是路线图中的第一个计划，因此我们希望将该计划分为 史诗 （此处以绿色，蓝色和青绿色显示）和每个史诗的用户故事。
然后，产品负责人将每个用户案例组织到一个单独的列表中，以供开发团队使用。产品负责人可以选择首先提供完整的史诗（左）。或者，对于程序而言，测试预订打折航班需要一些来自多个史诗的故事（右图）可能更重要。请参阅下面的两个示例。
什么会影响产品所有者的优先级？
- 客户优先
- 迫切需要反馈
- 相对实施难度
- 工作项之间的共生关系（例如，如果我们首先执行A，则B会更容易）
尽管产品负责人负责对待办事项进行优先级排序，但这并不是凭空完成的。有效的产品负责人寻求客户，设计师和开发团队的意见和反馈，以优化每个人的工作量和产品交付。
注意积压情况
构建产品积压后，定期维护它以与程序保持同步很重要 。产品负责人应在每次迭代计划会议之前检查积压，以确保优先级正确，并结合了上一次迭代的反馈。在敏捷圈子中，定期检查积压通常称为“积压整理”（有些人使用术语积压细化）。
一旦积压变大，产品所有者就需要将积压分为近期和长期项目。短期项目需要充分充实后才能贴上标签。这意味着已经草拟了完整的用户案例，已经整理出与设计和开发的协作，并且已经对开发进行了估算。长期项目可能仍然含糊不清，尽管从开发团队获得粗略估计以帮助确定优先级是一个好主意。这里的关键词是“粗糙”：一旦团队完全理解并开始处理这些长期项目，估计值就会改变。
积压订单是产品所有者和开发团队之间的联系。由于客户的反馈，改进的估算和新的要求，产品所有者可以随时自由地重新安排积压工作的优先级。但是，一旦进行了工作，就应将更改降到最低，因为它们会干扰开发团队并影响重点，流程和士气。 提示：
一旦积压超过团队的长期能力，就可以解决团队永远无法解决的问题。在团队的问题跟踪器中以特定的解决方案（例如“超出范围”）标记这些问题，以供以后进行研究。
要注意的反模式
- 产品负责人会在项目开始时对待办事项进行优先排序，但不会随着开发人员和利益相关者的反馈而对待办事项进行调整。
- 团队将待办事项上的项目限制为面向客户的项目。
- 积压文件保存为本地存储的文件，不经常共享，从而防止相关方获取更新。
产品积压的订单如何使团队保持敏捷？
精明的产品所有者会严格修饰其程序的产品积压，使其成为项目工作项的可靠且可共享的轮廓。
积压的问题会引发辩论和各种选择，从而使程序正常运行-并非所有事情都可以放在首位。
利益相关者将挑战优先事项，这很好。围绕重要内容进行讨论，可使每个人的优先事项保持同步。这些讨论建立了团队优先排序的文化，以确保每个人在计划上拥有相同的心态。
产品积压订单还可以作为迭代计划的基础。所有工作项都应包括在积压中：用户案例，错误，设计变更，技术债务，客户要求，回顾中的行动项等。这确保了每个迭代的总体讨论中都包含了每个人的工作项。然后，在开始迭代之前，团队成员可以与产品所有者进行权衡，以完全了解需要完成的所有事情。
提示：
产品负责人在待办事项中指定工作项的优先级，而开发团队则决定在待办事项中的工作速度。对于想要“推动”团队工作的新产品所有者来说，这可能是一种脆弱的关系。在我们的文章中了解有关进行中的限制和流程的更多信息。
