I urge everyone—no matter how big their portfolio—to truly understand every suggestion they’re given before acting.
The Portfolio Kanban system is a method to visualize and manage the flow of portfolio epics, from ideation through analysis, implementation, and completion.
There are several Kanban systems used throughout SAFe, including the team, program, solution, and portfolio Kanban systems. Each kanban system helps improve the flow of value through the Continuous Delivery Pipeline. Each system:
- helps match demand to capacity based on Work in Process (WIP) limits
- helps identify opportunities for relentless improvement by visualizing bottlenecks in each process state
- facilitates flow with policies governing the entry and exit of work items in each state
The portfolio Kanban is particularly important in that it helps align strategy and execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (Epics) for a SAFe portfolio. The portfolio Kanban is operated under the auspices of Lean Portfolio Management who use the strategic portfolio review and portfolio sync events to manage and monitor the flow of work.
The portfolio Kanban system describes the process ‘states’ that an epic goes through on its way from creation through completion. The advancement of the epic through the portfolio kanban is coordinated by the Epic Owner. Figure 1 highlights the benefits and structure of the portfolio Kanban system:
The Portfolio Kanban System
Figure 2 illustrates a design and an approach to implementing a portfolio Kanban system.
Each of the default portfolio Kanban states is described next. It’s important to note that these portfolio Kanban states represent an example process. The design of the Kanban may evolve to reflect improvements based on relevant portfolio experience. These improvements may include adjusting WIP limits, splitting or combining Kanban states, or adding classes of service to optimize the flow and priority of epics.
The funnel is used to capture all new big business or technology ideas. These ideas may originate as strategic concerns, ideas from ARTs or teams, or suggestions from customers and partners. These ideas are anticipated to be large enough to exceed the epic threshold Guardrail or perhaps have some other strategic or business model impact. If an initial review determines that an idea is not likely to exceed the epic threshold guardrail or be a portfolio concern, it is moved to the funnel of the Solution or Program kanban.
Portfolio Epics that arrive in the funnel are described simply with a short phrase, such as, ‘self-service for all auto loans.’ There are no WIP limits on this state as these are simply ideas that may deserve consideration.
While they can arise from any source, Figure 3 illustrates how epics typically flow into the funnel:
- The process of maintaining the Portfolio Vision and Roadmap identifies new initiatives that feed directly into the portfolio Kanban
- The Continuous Exploration process discovers user and market needs and often results in the identification of epics
Since epics are some of the most significant enterprise investments, someone needs to sponsor the epic and define its intent and definition. This happens in the reviewing state and is the responsibility of the Epic Owner.
When capacity is available, an Epic Owner pulls the Epic into this state where they work with other stakeholders to define the epic hypothesis statement (see Epic article). It has four main fields:
- Epic description – this is the structured ‘for-who-the …’ portion that describes the epic in general terms.
- Business outcome hypothesis – the anticipated quantitative or qualitative benefits if the hypothesis is proven to be true
- Leading indicators – the early measures that will help predict the business outcomes
- Nonfunctional requirements (NFRs) – attributes such as security, reliability, performance, maintainability, scalability, and usability that serve as constraints or restrictions
WIP limits for this state (number of epics allowed) may be specified. Alternatively, the lack of an Epic Owner who is available to do the work can serve as an implicit WIP limit.
Preliminary size and cost estimates and a first WSJF estimate relative to other items in the reviewing state is established. The epic is reviewed as part of the normal portfolio sync agenda. When there is sufficient knowledge and review, the epic may be approved as being ready for the analyzing state. If the epic does not appear sufficiently viable, it is simply moved to the done state, which frees capacity for more promising alternatives.
When the Epic Owner has the necessary capacity, and there is room available within the WIP limit, promising epics are pulled into analyzing. Epics that make it to this state merit more rigorous analysis and further investment. This typically requires active collaboration among the following roles:
- Business Owners
- System and Solution Architects/Engineering
- Product and Solution Management
- Agile Teams
During the analysis state, the following activities typically occur:
- Identification and review of solution alternatives
- Definition of the Minimal Viable Product (MVP)
- Establishing cost estimates for the MVP and the anticipated scope of the entire epic
- Creation of the Lean Business Case
- Small research spikes to establish potential technical and business viability
- Initial customer validation
- Updated WSJF with respect to other epics in this state
- Go/no-go decision by LPM based on the Lean business case
Typically there are only a small number of epics in this state and they are reviewed routinely by LPM. Since the eventual initiation of the epic will take precious capacity, approval to move into the next state is a more rigorous affair. WSJF is one factor, but there are many additional considerations that may also be applied.
During the portfolio sync, LPM uses the lean business case to make a ‘go/no-go’ decision. ‘Go’ confirms the epic is approved for implementation and sequenced using WSJF. ‘No-go’ moves the epic to done.
Epics in the analyzing state that have the highest WSJF are pulled into the next state, portfolio backlog, as soon as space is available. This is a low cost ‘wait state’ where epics are periodically reviewed and prioritized by updating WSJF and other relevant factors.
When sufficient capacity from one or more ARTs is available, the epics with the highest WSJF advances to the Implementing:MVP state. Here, the Epic Owner works with the Agile teams to begin the activities needed to develop the MVP and evaluate the business outcome hypothesis. Work on the MVP continues until the money allocated for the MVP has been spent or the hypothesis is proven or disproven.
If the value stream runs out of money to implement the MVP and the customer problem still exists, a new epic may be proposed and placed in the funnel state, or the epic is considered done and there is no further consideration.
If the hypothesis is proven true, the epic advances to the Implementing: Persevere state and teams will continue to implement additional features and capabilities for the epic. ARTs manage the additional investment via ongoing feature prioritization of the Program Kanban in various value streams. Eventually, the epic will be ‘done enough’ such that ongoing WSJF will prioritize new capabilities and features from other sources as higher priority.
From a portfolio perspective, an epic is considered done when sufficient knowledge or value is achieved such that the initiative is no longer a portfolio concern. Completion of the full envisioned scope from the Lean business case is not a criterion. Rather, the epic is considered done when:
- It is ejected from the portfolio kanban by LPM in any of the earlier states
- The MVP disproves the hypothesis
- The hypothesis is proven, but LPM has determined that additional portfolio governance is no longer required
In the latter case, work on the epic may continue by various ARTs and the Epic Owner may have some ongoing responsibilities for stewardship and follow-up. Since the epic itself is no longer a portfolio concern, leading indicators, value stream KPIs, and Guardrails are used to keep LPM informed of progress.
Managing the Portfolio Kanban with the Portfolio Sync and Strategic Portfolio review
The Lean Portfolio Management article describes two typical, cadence-based events, the strategic portfolio review and portfolio sync. During these meetings, LPM stakeholders review the portfolio Kanban system and agree on the movement of items through the system. They review the strategic alignment of initiatives in the Kanban, discuss new work, prioritize epics, and make ‘go/no-go’ decisions as needed.
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: 12 September 2020