I urge everyone—no matter how big their portfolio—to truly understand every suggestion they’re given before acting.
Portfolio Kanban Abstract
SAFe suggests the development and implementation of Kanban systems throughout the content hierarchy—Portfolio, Value Stream, Program, and Team. While these Kanban systems operate in a similar manner, and they interoperate, they are largely separate systems, they serve separate purposes, and they operate at different levels of abstraction. This article summarizes the implementation of the highest-level such system, the Portfolio Kanban system for Epics. This system controls much of the economics of the portfolio.
Implementation and management of the portfolio Kanban system is under the auspices of Program Portfolio Management. Implementing such a system requires a material understanding of Lean and Agile development practices as applied to Portfolio Level practices. It also requires an understanding of the productive capacity of each Agile Release Train, the velocity of each, and the availability of each for new developments and business-as-usual support activities. When these are understood, the Enterprise can start to reason about portfolio level initiatives in a logical and pragmatic way, with full knowledge of the actual implementation context.
The SAFe Portfolio management Kanban system is used primarily to address the flow of Epics, those large, cross-cutting initiatives that affect the course of action for Value Streams and the Agile Release Trains (ARTs) that realize them. Therefore the capture, analysis, approval, and release of epics into implementation is a material decision for the portfolio, one that requires participation of a number of key stakeholders, including Program Portfolio Management (PPM), and representation from the affected value streams and ARTs.
SAFe applies a Portfolio Kanban system in this context for a number of reasons:
- Make the strategic business initiative backlog fully visible
- Bring structure and visibility to the analysis and decision-making that moves these initiatives into implementation
- Provide WIP limits to ensure that the teams responsible for analysis undertake it responsibly and do not create expectations for implementation or time frames that far exceed capacity and reality
- Help drive collaboration among the key stakeholders in the business
- Provide a quantitative, transparent basis for economic decision-making for these, the most important business decisions
A Kanban System for Epics
All Kanban systems are designed for a specific purpose; this one is made to capture, analyze, approve, and track epics. This particular system might appear as depicted in Figure 1 below.
This portfolio Kanban system describes a number of stages that an epic passes through on the way to implementation (or rejection), and the collaboration that is required for each stage:
- Funnel – This is the capture state, where all new “big” ideas are welcome.
- Review – In this stage the preliminary estimates of opportunity, effort, and cost of delay are established.
- Analysis – This is where the more thorough work is done to establish viability, measurable benefit, development and deployment impact, and potential availability of resources. A lightweight business case is developed. The epic is approved or rejected at the end of this state.
- Portfolio Backlog – Epics that have made it through the portfolio Kanban with “go” approval wait in the Portfolio Backlog until capacity is available.
- Implementation – When capacity becomes available, epics are transitioned to the relevant Program and Value Stream Kanbans, where implementation begins. The reports described in Metrics can subsequently be used to track epics at the portfolio level.
- Done – The epic is done when it has met its success criteria.
Note: Because all Kanban systems are purpose-built, designing and implementing them is an evolving process within the context of each. In addition, such systems have additional mechanisms, such as capacity allocation in support of business epics versus Enablers, classes of service for work of various types based on cost of delay, use of swim lanes, methods for analyzing flow and seeing bottlenecks, adjusting WIP limits, and more. Such discussions are outside the scope of this article and may be found in the Guidance article Improving Flow with Kanban.
Description of the System
1. The Funnel
The Funnel queue is the “capture” queue, where all new “big ideas” are welcome. They can come from any source; they may be business or technical concerns. Typical drivers include:
- The portfolio Strategic Themes
- Unanticipated changes in the marketplace, business acquisitions, mergers, emergence of new competitors, etc.
- The need for substantive Solution cost savings or operational efficiencies
- Problems with existing solutions that hinder business performance
In this queue, epics need no business case or estimates. Epics can be stated in any format, typically as just a short keyword or phrase, such as “Self-service for all auto loans.” Tooling is trivial—a document, spreadsheet, or, better, a visual system on the wall will typically suffice. Since the investment of effort on items in this queue is minor, the queue is not WIP-limited. All ideas are captured for consideration. Funnel epics are discussed on a periodic cadence established by Program Portfolio Management. Epics that meet the decision criteria are promoted to the Review queue.
Epics that reach the Review queue warrant further investment of time. In this queue, epics are roughly sized and some estimate of value is established. Time investment is controlled to the discussion level, with perhaps some very preliminary investigation. The epic will be elaborated in the Epic Value Statement format (see Epic). Since the investment is increasing, this queue is WIP-limited to curtail the number of active items in process. Sources of business benefit are identified and items are prioritized using WSJF. Epics that rise to the top are pulled into the Analysis queue as soon as space is available.
Epics that make it into this queue deserve a more rigorous analysis and require further investment. An Epic Owner takes responsibility for the ongoing work. An active collaboration is initiated among the Enterprise Architects, System Architects, Agile Teams, Product and Solution Management, and key stakeholders on the potentially affected Agile Release Trains. Solution, design, and implementation alternatives are explored. Options for internal development and/or outsourcing are considered. A lightweight business case, with a go or no-go recommendation, is developed.
Items in this queue use scarce resources and, more important, imply a substantial upcoming investment. Therefore the capacity of the business analysts and of the development teams and enterprise architects, as well as the desired throughput rates for all items in this queue, combine to limit it according to WIP considerations. Promotion from Analysis to the Portfolio Backlog queue is an important economic decision for the Enterprise that can be made only by the appropriate authority, based on the developed business case. Epics that meet the go criteria are promoted to the portfolio backlog queue.
4. Portfolio Backlog
Items that have reached the portfolio backlog state have received a go decision from the appropriate authority, usually some subset of Program Portfolio Management. These epics are reviewed on a periodic basis (see below), and this queue represents a low-cost holding pattern for upcoming implementation work. Epics from this queue are promoted to the Implementing queue when there is sufficient capacity from one or more value streams or Agile Release Trains.
As capacity becomes available, epics are pulled into the relevant value stream and program Kanbans, where they usually undergo further analysis. An example of a method for balancing load and scope consistency cross multiple value streams in the portfolio can be find in the guidance article describing the Process and Simple Tool for Planning Portfolio Work. The epics are split into capabilities and features, and acceptance criteria are established. When ready, these new capabilities and features are presented at relevant PI Planning boundaries, including the Pre-Planning events in larger value streams. Actual implementation by the development teams then begins. The evolution of the solution in regular Program Increments (PIs) offers an excellent vantage point for objective evaluation of progress. Epics can be tracked to completion via appropriate metrics.
While the responsibility for implementation rests with the development teams, Epic Owners remain available on a “pull” basis and share responsibility until the teams have achieved a sufficient understanding of the work.
The epic is considered done when it has meet all of its success criteria. However, due to the scope of epics, “completion to original intent” is not always the desired case, so it’s likely that some identified capabilities and features are eventually discarded. In either case, the epic reaches a done state, and this marks the exit timing for the Cumulative Flow Diagram, if applied at this level.
Driving the Portfolio Work Flow with the PI Cadence
Many PPM teams use epic “review and specification workshops” to advance epics from left to right in the system. Such workshops typically involve portfolio stakeholders and content and technical authorities from the value stream or ART level. Together, the team reasons about the implications of solution strategies, identifies ways to split epics into epics/capabilities/features at the lower levels, and makes the decisions necessary to move an epic forward to the next state, hold it where it is, or reject it from the system. During this process, epics are validated against strategic themes and moved from Funnel to Review, and from Review to Analysis as WSJF and other data suggest. The lightweight business case is developed and reviewed. Finally a go/no-go decision is reached. Approved epics then move to the portfolio backlog where they await implementation capacity.
These workshops may or may not occur on a cadence, though cadence is preferred. However, the timing of implementation is driven by the cadence of the affected value streams and ARTs, so they must occur frequently enough to be able to provide input to each value stream/ART ahead of their target PI planning processes.
 SAFe Guidance article Improving Flow with Kanban.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
 Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Last update: 2 August 2016