I urge everyone—no matter how big their portfolio—to truly understand every suggestion they’re given before acting.
The Portfolio Kanban is a mechanism used to visualize, manage, and analyze the prioritization and flow of portfolio Epics from ideation to implementation and completion.
SAFe describes the development and implementation of Kanban systems throughout the Framework, at the Portfolio, Solution, Program, and Team levels. 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 logically and pragmatically, knowing the initial feasibility and forecasted timing for implementation.
The Portfolio Kanban system is used to address the flow of Portfolio Epics, those large, typically cross-cutting initiatives that affect the course of action for the ARTs and Solution Trains that realize them. This makes the capture, analysis, approval, and release of epics essential activities. They require participation from some key stakeholders, including LPM and representation from the affected trains.
The portfolio Kanban system provides many benefits:
- It makes the most significant business initiatives visible
- Brings structure to analysis and decision-making for epics
- Work in Process (WIP) limits ensure that the teams responsibly analyze epics
- It prevents unrealistic expectations
- Drives collaboration among the key stakeholders
- Supports a transparent and quantitative basis for economic decision-making
This portfolio Kanban system describes the process states (states) that an epic passes through on its way to implementation (or rejection) and the collaboration needed for each state, as shown in Figure 1. Each state of the Kanban is described next.
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:
- Unanticipated changes in the marketplace, business acquisitions, mergers, and response to competitors
- Improving the efficiency or cost of a solution or its operation
- Problems with existing solutions that hinder business or technical performance
Epics are typically described using a short phrase on card, such as, “self-service for all auto loans.” 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 just 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 the article, 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, and Product and Solution Management. Other key stakeholders in 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 outsourcing are also considered.
- Most importantly, (see the article, 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 or not the ‘epic hypothesis statement’ is validated. 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. The approval of epics is a critical 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 – This state 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) boundaries (PI Planning), including Pre-PI Planning events in Solution Trains. Then the development teams begin implementation. The solution is developed during regular PIs, and the PI Milestones provide the 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 to 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, A 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 of work item 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. 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.
Feeding the Portfolio Funnel
Figure 2 illustrates how epics flow into the funnel of the Portfolio.
- The Portfolio Vision and Roadmap drives creating business and enabler portfolio epics that feed directly into the Portfolio Kanban.
- The Continuous Exploration process involves continually exploring the market and user needs and often results in the identification of epics. If the epics exceed the portfolio epic threshold as described in Guardrails, these epics go into the portfolio funnel for consideration by LPM.
Driving the Portfolio Workflow 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:
- As WSJF and other data recommend, epics are validated against strategic themes and moved from ‘funnel’ to ‘reviewing,’ and from ‘reviewing’ to analyzing.
- Solution strategies are discussed.
- Lightweight 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 a 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. [2 ] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Last update: 21 September 2018