I urge everyone—no matter how big their portfolio—to truly understand every suggestion they’re given before acting.
The Portfolio Kanban is a method used to visualize and manage the analysis, prioritization and flow of portfolio epics from ideation to implementation and completion.
SAFe describes the development and implementation of Kanban systems throughout the framework—Portfolio, Solution Level, Program, and Team. The portfolio Kanban visualizes the flow of new strategic initiatives, known as Epics, controlling much of the economics of the portfolio.
Implementation and management of the portfolio Kanban system occur with the support of Lean Portfolio Management (LPM). Implementing the Kanban system requires an understanding of Lean and Agile development as it applies to Portfolio-Level practices. It also requires understanding the capacity for each Agile Release Train (ART), and how much is available for new development, business-as-usual maintenance, and support activities. When these are understood, the Enterprise can then evaluate portfolio-level initiatives in a logical and pragmatic way, knowing the initial feasibility and forecasted timing for implementation. The portfolio Kanban system is designed specifically for this purpose.
The SAFe Portfolio Kanban system is used primarily to address the flow of epics, those large, cross-cutting initiatives that affect the course of action for the Solution Trains and Agile Release Trains (ARTs) that realize them. This makes the capture, analysis, approval, and release of epics into implementation important activities. They require participation from a number of key stakeholders, including Lean Portfolio Management (LPM) and representation from the involved Solution Trains and ARTs.
SAFe uses the portfolio Kanban system for a number of reasons:
- It makes the largest business initiatives visible.
- The system brings structure to analysis and decision-making.
- WIP limits ensure that the teams analyze epics responsibly.
- It prevents unrealistic expectations.
- Kanbans drive collaboration among the key stakeholders.
- It provides a transparent and quantitative basis for economic decision-making.
A Kanban System for Epics
The portfolio Kanban is designed to capture, analyze, approve, and track epics, as illustrated in Figure 1.
This portfolio Kanban system describes the states that an epic passes through on its way to implementation (or rejection), and the collaboration needed for each state:
Funnel – the Funnel is used to capture all new “big ideas.” They can come from any source, and may be business or technical concepts (enablers). Typical drivers of epics include:
- Portfolio Strategic Themes
- Unanticipated changes in the marketplace, business acquisitions, mergers, response to competitors, etc.
- Improving the efficiency or cost for a solution or its operation
- Problems with existing solutions that hinder business or technical performance
Epics are typically described using a short phrase, such as, “self-service for all auto loans” on a Kanban card. After all, the investment in Funnel epics should be minimal until they are discussed on a periodic cadence established by LPM. Epics that meet the decision criteria are then moved to the next state, ‘Reviewing.’ There is no WIP limit for this state since it’s simply used for intake of potential new epics.
Reviewing – Epics that reach this state warrant some further time and effort. Here, they are roughly sized, along with an estimate of value. Time investment is limited to the discussion level, with perhaps some preliminary investigation. Next, the epic will be elaborated in the Epic Hypothesis Statement format (see epic). Since the investment of time is now increasing, a WIP limit is applied to restrict the number of epics being reviewed. Sources of business benefit are identified and epics are prioritized using Weighted Shortest Job First (WSJF). Epics that rise to the top are pulled into the next state, ‘Analyzing,’ as soon as space is available in the Kanban.
Analyzing – Epics that make it to this state merit more rigorous analysis and require further investment. Epic Owners take responsibility for this ongoing work. They establish an active collaboration among Enterprise Architects, System and Solution Architects, Agile teams, Product and Solution Management. Other key stakeholders on the potentially involved ARTs and Solution Trains may also be included. Alternatives are explored for the Solution and its design and implementation. A lean business case, with a ‘go’ or ‘no-go’ recommendation, is developed; and options for internal development and/or outsourcing are also considered.
Most importantly, (see epic) a Minimum Viable Product (MVP) is developed after the Lean Startup Cycle. It includes the smallest portion of the epic needed to understand whether the ‘Epic Hypothesis Statement’ is true or not. This MVP will be the part of the epic flowing through the rest of the portfolio Kanban system.
Since epics in this state use scarce resources and, more importantly, imply a substantial upcoming investment, a WIP limit is applied here. The approval of epics is an important economic decision from the Enterprise. It can only be made by the appropriate authority, based on the developed business case. Epics that meet the ‘go’ criteria are usually approved by a subset of LPM and are moved to the ‘Portfolio Backlog’ state.
Portfolio Backlog -The portfolio backlog is used to maintain epics that have been approved by LPM. They’re reviewed and prioritized on a periodic basis using WSJF. When sufficient capacity from one or more ARTs is available, the item advances to the ‘Implementing’ state.
Implementing – As capacity becomes available, epics are pulled into the relevant Solution or Program Kanban, where they usually undergo further analysis. For example, the epics are split into capabilities and features, and acceptance criteria are established.
When ready, these new capabilities and features are presented at the relevant Program Increment (PI) Planning boundaries, including Pre-PI Planning events in Solution Trains. Then the development teams begin implementation. The solution is developed during regular Program Increments (PIs), and the PI milestones provide objective evaluation of progress. Epics can be tracked to completion via appropriate metrics. While responsibility for implementation rests with the development teams, Epic Owners remain available on a ‘pull basis’ and share responsibility until the teams have attained a sufficient understanding of the work.
For more information on implementing epics, please refer to the guidance article entitled, ‘Process and Simple Tool for Planning Portfolio Work.’
Done – Once its anticipated outcome has been evaluated, the epic is considered done. If the hypothesis is proven, more work will be done by features, capabilities, or epics. If the hypothesis is refuted, however, the portfolio would pivot to another approach, or drop the initiative altogether. 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 may eventually be discarded. In either case, the epic advances to ‘Done,’ and this marks the completion for the Cumulative Flow Diagram (CFD), if applied at this level.
The portfolio Kanban states detailed above represent an example of the process. After the initial states are taken and new learning occurs, the design of the Kanban should evolve to reflect improvements in the process. This may include adjusting WIP limits, splitting or combining states, or adding classes of service to optimize the flow and priority of epics. These discussions are outside the scope of this article and may be found in the guidance article, Improving Flow with Kanban. It’s also important to note that the Kanban system works in tandem with additional SAFe mechanisms, such as capacity allocation, which is used to balance the development of ‘business epics’ versus ‘enabler epics.’
Driving the Portfolio Work Flow with the PI Cadence
In the Kanban system, an ‘epic review and specification workshop’ is often useful to advance epics from left to right. Such workshops typically involve portfolio stakeholders and content and technical authorities from the Solution Trains or ARTs. During these workshops, the following types of activities may take place:
- Epics are validated against strategic themes and moved from ‘Funnel’ to ‘Reviewing,’ and from ‘Reviewing’ to ‘Analyzing’ as WSJF and other data recommend.
- Solution strategies are discussed.
- Lean business case and go/no-go decisions are developed
- Ways to split epics are identified. They may be split into program and solution epics, capabilities or features.
These workshops may or may not occur on a cadence, but cadence is preferred. However, the timing of implementation is driven by the cadence of the particular Solution Trains and ARTs. So they must take place frequently enough to be able to provide input ahead of their target PI planning processes. .
Learn More 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: 28 May, 2017