I urge everyone—no matter how big their portfolio—to truly understand every suggestion they’re given before acting.
—Suze Orman
The Portfolio Kanban is a method 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 of the capacity for each Agile Release Train (ART) and the portions of that capacity available for new development, business-as-usual maintenance, and support activities. When these issues are well understood, the Enterprise can evaluate portfolio-level initiatives logically and pragmatically, knowing the initial feasibility and forecasted timing for implementation. The portfolio Kanban system is explicitly designed for this purpose.
The portfolio Kanban system is used primarily to address the flow of epics, those large, crosscutting 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. Their implementation requires the participation of 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.
It 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.
It drives collaboration among the key stakeholders.
It provides a transparent and quantitative basis for economic decision-making.
The portfolio Kanban system describes the process states (steps) that an epic passes through on its way to implementation (or rejection) and the collaboration needed for each state (Figure 1). Each state of the Kanban is described next.
Figure 1. Portfolio Kanban system and typical collaborators
The funnel is used to capture all new big ideas. Epics can come from any source and may be business or technical initiatives (enablers). These large initiatives are often the result of the following drivers:
Portfolio strategic themes
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 a Kanban card, such as ‘self-service for all auto loans.’ 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 step since it’s just used for intake of potential new epics.
Epics that reach the reviewing state warrant some further time and effort. In this state, they are roughly sized and an estimate of their value is developed. 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 Epic chapter). 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 the Weighted Shortest Job First (WSJF) model. Epics that rise to the top are pulled into the next state, analyzing, as soon as space is available in the Kanban.
Epics that make it to the analyzing step 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/no-go’ recommendation) is developed, and options for internal development and outsourcing are considered.
Most importantly, 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 validated. This MVP will be the part of the epic flowing through the rest of the portfolio Kanban system. (See the Epic chapter for more information about developing the MVP and the Lean Startup Cycle.)
Since epics in the analyzing step use scarce resources and, more importantly, imply a substantial upcoming investment, a WIP limit is applied here. The approval of epics is a critical economic decision for the enterprise. These decisions can be made only 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.
The portfolio backlog holds epics that have been approved by LPM. These epics are reviewed and prioritized on a periodic basis using WSJF. When sufficient capacity from one or more ARTs is available, the epic advances to the implementing state.
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. The development teams then begin their 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.
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. Conversely, if the hypothesis is not proven, the portfolio may 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. Instead, 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 here represent an example of the process. After the initial steps are taken and new learning occurs, the design of the Kanban should evolve to reflect improvements in the process. For example, the enterprise may adjust the WIP limits, split or combine states, or add classes of service to optimize the flow and priority of epics. 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.
In the Kanban system, an epic review and specification workshop is often useful to advance epics from left to right in the process depicted in Figure 1. 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 ARTs and Solution Trains, so these workshops must take place frequently enough to be able to provide input ahead of their target PI planning processes.
LEARN MORE
[1] 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.