Portfolio Kanban

The Portfolio Kanban system provides a way to visualize, analyze, prioritize, and track an organization’s opportunities and strategic initiative (via the flow of portfolio Epics in SAFe). It enables transparency and traceability around decision-making while also encouraging management to stay focused only on the projects that matter most.

In this way, it empowers stakeholders to make decisions based on a unified set of data and facts—all in an effort to drive greater alignment. It also forces teams to list out all of the projects happening in real-time to ensure that none—especially small projects managed by individual teams—don’t inadvertently slip from the management team’s purview.

The system has three main objectives:

1. Expose reality and get everyone aligned around the current state of things.
2. Adjust resources and processes for implementing initiatives within a set timeframe.
3. Anticipate cross-team dependencies or potential bottlenecks in order to streamline organizational structures and improve how work gets scheduled across teams.

The Scaled Agile framework suggests a Kanban structure where Epics go through six primary steps: Funnel, Reviewing, Analyzing, Portfolio Backlog, Implementing, and Done.

Funnel

The Funnel step is used to capture all strategic ideas—whether they come from management, stakeholders, customers, teams, or otherwise. For an idea to make it onto the Portfolio Kanban, they must be larger than something that could easily be dealt with at the Solution or Program level (which would lead to a single, short-phase Epic).

Reviewing

In the Reviewing step, the Epic Owner builds the Epic hypothesis statement based on the Scaled Agile framework, which includes the following components:

• Description of the Epic
• Business outcome hypothesis: The expected benefits if the hypothesis is true.
• Leading indicators: The KPIs used to predict the business outcome.
• Non-functional Requirements: Elements related to security, reliability, performance, maintainability, scalability, and usability that could pose constraints or restrictions.

Here, you should also estimate the Epic’s size and cost in order to compare it to other Epics.

Analyzing

The most promising Epics from the step above are added to the Analyzing column. At this stage, all operational teams collaborate on what it will take to implement this Epic, including:

• Identification and the review of solution alternatives
• Definition of the MVP (Minimum Viable Product)
• Estimate of the MVP’s cost
• Initial user testing and feedback (if possible)
• Updated business value/cost comparison (to other Epics at this stage)

Based on this analysis, management can make a well-informed “Go” or “No Go” decision before pushing the Epic further along in the process.

Portfolio Backlog

This column outlines all of the Epics that the team has chosen to implement.

Implementing

At this stage, the MVP is implemented for the purpose of testing and validating the Business Outcome Hypothesis as it was defined in the Reviewing step. Based on these initial results, the Epic can either be considered “done” or, if additional features still need to be implemented, the team can allocate more resources to ensure this work gets done.

Done

There are only really two potential outcomes at this stage:

• The MVP proves the Business Outcome Hypothesis to be true
• The MVP proves the Business Outcome Hypothesis to be false

Regardless of the outcome, the Epic is considered “done” at this point because sufficient knowledge or value has been achieved. It is no longer a portfolio concern for the team.

Lean and Agility-at-Scale consultant William Baxter suggests an Epic should include the following data:

• Epic Title
• Teams involved in the implementation
• Epic Owner
• Epic Description
• Dependencies
• Due date
• Epic Type (ex: strategic, infrastructure, innovation, legal, etc.)
• Effort Level (or Cost Estimate)
• Business Value

In addition to these fields, it is also recommended to leave a space for miscellaneous notes.