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. These systems help match demand to capacity based on Work in Process (WIP) limits, and visualizing bottlenecks in each process state helps identify opportunities for relentless improvement. Kanban systems also include policies governing the entry and exit of work items in each state. The portfolio sync event (see the Lean Portfolio Management competency article) is a cadence-based event in which LPM reviews and manages the epics within the portfolio kanban.
Implementation and management of the portfolio Kanban system occur with the support of Lean Portfolio Management (LPM), and other key stakeholders. Applying the Portfolio Kanban system requires an understanding of Lean-Agile development and the lean budget guardrails chosen by the portfolio. Figure 1 illustrates the many benefits of the portfolio Kanban system:
The Portfolio Kanban System
The portfolio Kanban system (Figure 2) describes the process states that an epic goes through on its way to from creation through completion. The advancement of the epic through the portfolio kanban is coordinated by the epic owner.
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 should evolve to reflect improvements the default Kanban states 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 ideas. They may originate as strategic concerns or ideas from ARTs or teams that are likely to exceed the epic threshold guardrail. As a result, epics may come from any source and can be business or technical initiatives. Figure 3 illustrates the typical drivers of epics. Epics in the funnel are described with a short phrase on a Kanban card, such as, ‘self-service for all auto loans.’
Figure 3 illustrates how epics typically flow into the funnel:
- Maintaining the Portfolio Vision and Roadmap often result in identifying new initiatives that feed directly into the portfolio Kanban
- Since the Continuous Exploration process discovers user and market needs it often results in the identification of epics
Since epics are some of the most significant enterprise investments, stakeholders need to agree on the epic’s intent and definition. However, the time investment during the reviewing state should be small. Therefore, the epic hypothesis statement (see Epic article) defines this intent, which 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
Epics in the reviewing state with the highest WSJF are pulled into the next state, analyzing, as soon as space is available.
Epics that make it to this state merit more rigorous analysis and require further investment. Epic Owners take responsibility for establishing an active collaboration among the following roles to analyze the epic:
- 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)
- Cost estimates for the MVP and the anticipated scope of the entire epic
- Creation of the Lean Business Case
- Go/no-go decision by LPM based on the Lean business case
Since initiatives in this state require busy individuals and other scarce resources and, more importantly, imply a substantial upcoming investment, a WIP limit is applied. Approved 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 state is used to maintain epics that have been approved by LPM. Here they are also reviewed and periodically prioritized using WSJF. When sufficient capacity from one or more ARTs is available, the items with the highest WSJF advance to the implementing state.
Due to their strategic value and size, epics are implemented using a ‘build-measure-learn’ cycle (see the Epic article).
After being approved for implementation, the Epic Owner works with the Agile teams to begin the activities needed to develop the MVP and evaluate the business outcome hypothesis:
- If the hypothesis is proven true, teams will implement additional features and capabilities for the epic or possibly new epics. ARTs manage the additional investment via ongoing feature prioritization of the Program Kanban in various value streams.
- However, if the hypothesis is proven false, the LPM fiduciaries can decide to pivot by creating a new epic or dropping the initiative altogether.
From a portfolio perspective, an epic is considered done when sufficient knowledge or value is achieved. Completion to the full envisioned scope from the Lean business case is not required. The epic is considered done when:
- The business outcome hypothesis is proven false
- 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. Leading indicators, Value stream KPIs, and Guardrails are used to keep LPM informed of progress.
Managing the Portfolio Kanban with the Portfolio Sync
During the Portfolio sync meeting, LPM, Epic Owners, and Agile Program Management Office (APMO) personnel review the portfolio Kanban system and agree on the movement of items through the system. They also 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: 29 June 2020