If you don’t scale the mountain, you can’t view the plain.
– Chinese Proverb
Portfolio Level Abstract
The highest level of the Big Picture Framework is the Portfolio Level, where programs are aligned to the enterprise business strategy and investment intent. While not specifically indicated on the Big Picture, the portfolio can be applied in the context of one specific release train, or a single portfolio planning mechanism may govern multiple release trains. To scale to this level, we will again need to scale value, teams, and timebox.
Value – We scale the backlog with the introduction of investment themes, which allocate budget to various initiatives, and, in turn, drive the portfolio vision and architectural runway needed to turn this vision into reality. These are encapsulated in various business and architectural epics, which are managed via kanban systems.
Team – The portfolio backlog is typically the responsibility of portfolio management, those top-level authorities who make the long-term investment decisions that drive overall business performance. This responsibility often falls to those director/VPs who have the responsibility and accountability for the “spend” in their business unit or product line.
Timebox – While presentation of platform vision and discussion of longer-term epics are synchronized to the PSI/Release planning cycle (8-10 weeks), the portfolio planning cycle is necessarily longer, and investment plans may be reviewed and adjusted on a twice-annual or annual budgeting cycle. Moving to a more incremental and more Agile budgeting cycle (at least twice annual) increases business agility.
The Portfolio level employs a number of key constructs:
- Investment Themes
- Architectural Runway
- Portfolio Vision
- Portfolio Backlog
- Kanban Systems
- Portfolio Management Team,
each of which are described in the sections below.
Investment Themes represent the set of initiatives that drive the enterprise’s investment in systems, products, applications, and services. Investment themes represent key product or service value propositions that provide marketplace differentiation and competitive advantage.
The set of strategic investment themes for an enterprise, or business unit within an enterprise, establishes the relative investment objectives for the entity. Each “partition” in the pie-shaped graphic represents a specific development initiative and an associated budget. Within the partition (budget allocation), managers are empowered to develop the initiative in whatever way makes the most economic and business sense for the enterprise. However, they generally may not exceed the budget or borrow resources from other themes without agreement from those stakeholders. With this process, the enterprise exercises its fiduciary responsibility by driving investment to the agreed-to business priorities. In most organizations, these decisions happen at the business unit level based on annual or twice-annual budgeting process.
The set of strategic investment themes drive all new development, and Epics are derived from these decisions. Epics are large-scale development initiatives that realize the value of investment themes. There are two types of epics: Business Epics, which are functional or user-experience epics, and Architecture Epics, which are used to implement the technological changes that must be made to significant elements of the portfolio.
Derived from strategic investment themes, business epics are development initiatives intended to deliver the value of the theme. Business epics are large, customer-facing initiatives intended to deliver new products, solutions, or services to the marketplace; they are identified, prioritized, estimated, and maintained in the Portfolio Backlog. Business epics may be stand-alone (developed in a single program or business unit) or they may cut across three dimensions:
- Time—affecting multiple releases of products, systems, services, or solutions
- Scope—affecting multiple products, systems, services, or solutions
- Organization—affecting multiple teams, programs, business units
In some cases, a large epic will spawn a number of epics for individual programs, business units, and so on. To manage this allocation, some have found it convenient to split these epics into subepics, which create an additional level in the hierarchy.
Architectural epics are the larger-scale technology initiatives, or infrastructure enablers, that describe how we need to evolve our system so that it meets the needs we have identified today, as well as allows us to exploit new opportunities that present themselves in the future. Like business epics, architectural epics are large, technology development initiatives that cut across one or more of three dimensions: time, scope, and organization.
Of course, we wouldn’t invest in architectural epics if they didn’t deliver any value, but it isn’t only user value that we must consider. There are other forms of value, including the value to our business in efficiency, operating, or transaction costs.
A system that has Architectural Runway contains existing or planned infrastructure sufficient to allow incorporation of current and anticipated requirements without excessive refactoring. In the context of the enterprise’s portfolio of products and in the face of a series of shorter, incremental releases, architectural runway is the answer to the big question: “What technology initiatives need to be underway now so that we can reliably deliver a new class of features in the next year or so?”
These initiatives are not side R&D projects that an enterprise may use to determine technology strategies, establish feasibility, and so on. Those are localized efforts and can be managed fairly easily by the teams or the System Architects. Rather, these are large-scale changes to the code base (example: move to JBOSS) that will be necessary to support epics and features on the current roadmap and changes that could affect most, or even all, of the development teams.
Portfolio Vision and Backlog
The Portfolio Vision provides visibility as to how investment themes will be realized via business epics over time. The domain of the portfolio vision may be a single program (Agile Release Train) but is more likely to affect multiple release trains in the enterprise or within a specific business unit. Epics deliver the value implied by the theme, and they are identified, prioritized, estimated, and maintained in the Portfolio Backlog.
Many epics are derived from the portfolio vision or roadmap; they have been identified sometime in the past and are now reaching an appropriate implementation horizon. Epics on the portfolio backlog may also originate from new opportunities, such as unanticipated changes in the marketplace, business acquisitions, entry of new competitors, and so on. Still other epics may be based on cost savings or other operational efficiencies.
- Visualize the flow of epic-level value through analysis and into implementation
- Limit work in progress to assure flow
- Drive an effective collaboration with the development teams
- Provide a quantitative basis for economic decision making
- Make policies with respect to capacity allocations explicit
Each system employs four queues (funnel, backlog, analysis, and implementation) to manage the workflow.
Portfolio Management Team
The Portfolio Management team consists of those individuals who have ultimate responsibility for the lines of business. This team makes decisions based on some combination of the following:
- Investment in existing product offerings—enhancements, support, and maintenance
- Investment in new products and services—products that will enhance revenue and/or gain new market share in the current or near-term budget period
- Investment in futures—advanced product and service offerings that require investment today but will not contribute to revenue until outlying years
- Reducing investment (sunset strategy) for existing offers that are nearing the end of their useful life
To provide ongoing governance and visibility into the investments, the portfolio management team may be assisted by a project management office (PMO).
Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Portfolio. Addison-Wesley, 2011..
Last update: 15 January, 2013
© 2010-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.