产品backlog是一份包含开发产品所需的所有工作事项的优先级清单。这些事项包含功能、缺陷（如果产品正在生产中，或者在之前的sprint中已经发布了）、文档变更及PO提出的其他任务。Backlog的维护，借助的是sprint期间的梳理过程。PO利用从干系人、业务代表处获得的输入，在Scrum团队的协助下进行优先级排序。尽管有团队的协助，但PO仍对优先级的排序负有完全的责任。

利用CMMI的需求管理过程域，改善敏捷中的产品backlog

产品backlog是一个带有前后顺序的列表，其包含了开发产品所需的每一个事项，是产品变更需求的唯一来源。无论你的敏捷实践如何开展，产品backlog都是敏捷项目的基础。好的backlog会造就好的项目产出。CMMI中的需求管理过程域，提供了许多最佳实践，帮助敏捷团队确保在创建和提炼backlog时，不遗漏任何重要事项。

·    敏捷需要透明度，CMMI尤其围绕需求，充实了这一点。利用与需求干系人之间的验收标准及公开的沟通渠道，使epic和user story变得清楚明了。

·    强调“让团队做出工作承诺，是产品开发的重要环节”这一思想。这样的承诺会最终体现在sprint策划会议上，并被高质量的backlog事项所强化。

·    随着时间的推移加强管理产品backlog变更。CMMI强调，在进行变更分析与决策时，应该让干系人参与其中，这一点经常被忽略。

需求管理过程域的信息组件，将为产品backlog事项的健壮性提供优秀的资源。

利用CMMI的集成项目管理过程域，改善敏捷中的产品backlog

产品backlog是一个包含开发产品所有事项的优先级排序列表。大型项目有大量的产品backlog，因此交付这样的项目，需要多团队在sprint中同步进行。多团队的协作将会使项目管理变得复杂，并且会对项目的成本、质量与时间产生潜在的消极影响。诸如Scrum这样的敏捷框架是轻量级的管理框架，它没有说明如何对大型的敏捷项目进行管理，在执行上，留有空白。敏捷使用者可以借助CMMI中的集成项目管理过程域中的实践，来填补这一空白：

·    识别大型项目中，其他需要纳入产品backlog中的计划，比如培训计划、后勤计划、设备计划、配置管理计划、集成计划等。

·    需要考虑如何收集意见一致且有用的改进信息，并在多个敏捷团队之间分享，比如从sprint回顾中学到的经验就是一个例子。

·    一种backlog优先排序方法，说明了跨多个敏捷团队的关键路径管理，它的目标是理解和解释相互依赖关系。

复杂项目的管理普遍具有挑战性与风险性。集成项目管理过程域的信息组件，为多敏捷团队的高效管理提供了帮助。

利用CMMI的项目策划过程域，改善敏捷中的产品backlog

产品backlog包含了向产品的内外部客户交付完整解决方案的全部epic与user story。致力于在每个sprint结束时，交付功能性的软件是敏捷实践的显著应用。然而，交付软件所需的事项众多，这些都应被作为产品backlog的一部分，以确保项目估算完整且满足承诺。那么问题来了，一份详尽的产品backlog，应该包含什么样的内容呢？CMMI集成项目管理过程域给出了答案：

·    关键客户或内部项目里程碑，如向客户提交原型，或退出某个节点或阶段所需的信息是一定要涵盖在backlog中的。与敏捷团队交互的其他支持团队，需要对理解更高层级的里程碑充满信心。

·    培训项目成员。产品backlog本身，就可能会涉及到培训的细节（如，培训的方法、时间限制与讲师）。在sprint期间，经验丰富的敏捷团队成员的backlog，可能会包括培训低经验值的成员的事项。

创建一个完整的项目计划，是任何项目成功的关键输入。CMMI的项目策划过程域，为此提供了有用的参考。