Big-Picture Elements: Portfolio Level
Figure 2-4 summarizes the Portfolio level of the Big Picture.
Figure 2-4 Portfolio level of the Big Picture
At the top of the Big Picture, we find the portfolio management function, which includes those individuals, teams, and organizations dedicated to managing the investments of the enterprise in accordance with the enterprise business strategy. We also find two new artifact types, investment themes and epics, which together create the portfolio vision.
A set of investment themes establishes the relative investment objectives for the enterprise or business unit. These themes drive the vision for all programs, and new epics are derived from these themes. The derivation of these decisions is the responsibility of the portfolio managers, either line-of-business owners, product councils, or others who have fiduciary responsibilities to their stakeholders.
The result of the decision process is a set of themes—key product value propositions that provide marketplace differentiation and competitive advantage. Themes have a much longer life span than epics, and a set of themes may be largely unchanged for up to a year or more.
Epics and the Portfolio Backlog
Epics represent the highest-level expression of a customer need. Epics are development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog. Prior to release planning, epics are decomposed into specific features, which in turn are converted into more detailed stories for implementation.
Epics may be expressed in bullet form, in user-voice story form, as a sentence or two, in video, in a prototype, or indeed in any form of expression suitable to express the intent of the product initiative. With epics, clearly, the objective is strategic intent, not specificity. In other words, the epic need only be described in detail sufficient to initiate a further discussion about what types of features an epic implies.
In Chapter 1, we described how design (architecture) and requirements are simply two sides of the same coin—the "what" and the "how." In this book, we'll have time to explore this topic in more detail, and we'll provide some discriminators that help us think about the differences in architecture and requirements, as well as the commonalities. However, even though this book focuses on requirements, we can't ignore architecture, because experience tells us that teams that build some amount of architectural runway, which is the ability to implement new features without excessive refactoring, will eventually emerge as the winners in the marketplace. So, any effective treatment of agile requirements must address the topic of architecture as well.
Therefore, system architecture is a first-class citizen of the Big Picture and is a routine portfolio investment consideration for the agile enterprise.