最后一个章节的学习为项目组合层面的学习，在这一个层面，又新引入了两种新的工件：投资主题和篇章，一个新的待办事项（项目组合待办事项），一种新的团队（项目组合管理团队），和一些容器概念即项目组合愿景与架构跑道。
投资主题（或产品主题）代表推动企业在系统、产品、应用或服务中投资的倡议集合。
所有的新开发都是由战略投资主题集驱动的，而且需求的篇章（epic）也是从这些决策中提取的。篇章是大规模的开发行动，它们实现投资主题的价值。篇章是最高级别的需求工件，它可以用于协调开发。对篇章的表达可以采取条目的形式，使用一到两句话表述或者以视频、原型、用户界面实体模型的形式，也可以是适于表达其产品倡议意图的任何形式。通过篇章，目标具有可视性，但并不具体。换句话说，对篇章的描述只需要足以引发关于该篇章暗含何种类型特性的讨论即可。
接下来便是架构跑道和架构篇章，产品系统内的架构跑道，包含现有或计划中的基础设施，它们能够满足当前和预期需求而不必过分重构。书中在这里讨论的，不是企业用来决定技术战略、确定可行性等的一些研发项目，那是一些局部性的工作，可以由团队或系统架构师相对方便地管理。我们在这里讨论的，是对代码基的大规模修改，这样的修改对于支持实现当前路线图中的特性是必需的，而且这样的修改可能影响到大多数甚至所有的开发团队。
架构跑道：项目组合、项目集和团队。项目组合：在项目组合层面实现架构跑道，是通过定义、交流并实现一些架构篇章来达到的，而架构篇章驱动着企业的技术愿景。有些篇章需要大量的投资而且消耗大量资源，从近期角度看，有些架构篇章甚至会降低新特性的当前实现速度。由于不实现它们将最终危及企业的市场地位，架构篇章必须与任何其他篇章一样是可见的、经过评估和计划。项目集：在项目集层面，由产品经理、系统团队、项目集团队和架构师把架构篇章转化成与各发布相关的一些架构特性。这些架构特性，和其他特性一样，要经过排列优先级、评估和准备资源。而且，与特性一样，每个架构倡议也必须在每次发布边界在概念上完成，从而不危及新的发布。团队：在团队层面，为了扩展架构跑道，经常要运用一些重构穿刺和设计穿刺，而且它们与用户故事一起排定优先级。以这种方式，架构工作在每个边界都是可见、可说明和可演示的。为此，需要系统架构师、产品负责人和敏捷技术主管协调合作，以便确定要实现哪些故事穿刺以及实现时间。
体会：这是第一部分的最后章节，介绍了全景图中最高层的项目组合层面。介绍了管理敏捷企业级需求所必需的一些成分，包括战略投资主题、篇章、项目组合待办事项和架构跑道的概念。还介绍了项目组合管理团队作为一个职能单元为企业发展确立产品和服务的战略方向。经过长时间的阅读，书籍的第一部分已经全部学习完毕，从整体上来讲，敏捷企业完整的精益、可伸缩的需求模型如图所示：
