Portfolio Kanban

What does Portfolio Kanban stand for?

The Portfolio Kanban system provides organizations with a way of visualizing, analyzing, prioritizing, and tracking strategic opportunities and initiatives (Epics in SAFe) at the organizational level. It encourages transparency and brings traceability at the top level of the organization while supporting culling and forcing management to focus on what matters most.

Portfolio Kanban helps stakeholders make decisions based on the same data and facts, and align accordingly. It also forces management to reveal shadow projects that may occur at the operational level. It has three main objectives:

• Show reality and get everyone aligned about how things are,
• Adjust organization resources and processes to implement strategic initiatives in the targeted timeframe,
• Anticipate cross-team dependencies and potential bottlenecks to adapt the scheduling of the workload and the structuring of the organization.

What are the main stages of the Portfolio Kanban system?

Scaled Agile proposes a Kanban structure in which an epic can go through 6 steps: Funnel, Reviewing, Analyzing, Portfolio Backlog, Implementing, Done.

Funnel
The funnel column is used to capture strategic ideas whether they come from management, customers, teams, or have other origins. To be entitled to enter the Portfolio Kanban, you must ensure that those ideas are large enough and could not rather be dealt with at the Solution or the Program level. At this stage, just describe the Epic with one short phrase.

Reviewing
In the reviewing stage, the Epic Owner defines the Epic further and more particularly the epic hypothesis statement. Scaled Agile suggests filling in four fields:

• Epic description
• Business outcome hypothesis: the expected benefits for the organization if the hypothesis is proven to be true
• Leading indicators: the KPI that will help predict the business outcome
• Nonfunctional requirements: any elements about security, reliability, performance, maintainability, scalability, and usability that serve as constraints or restrictions

At this step, you also have to estimate a preliminary idea of the Epic’s size and cost and compare the opportunity to other epics.

Analyzing
After being reviewed and prioritized a first time at the previous stage, promising epics are added to the analyzing column. Here all operational teams collaborate to analyze further what it takes to implement this epic, in particular:

• The identification and the review of solution alternatives,
• The definition of the MVP (Minimum Viable Product),
• The estimation of the MVP’s cost,
• An initial customer validation when possible, and
• An updated business value/cost comparison to other epics at this stage.

Based on this analysis, management is able to make an informed go/no go decision and eventually push the epic to the following state.

Portfolio Backlog
This column gathers the few epics ready to implement.

Implementing
The MVP is implemented to evaluate the business outcome hypothesis defined previously. Based on the results, the epic can be considered done once implemented as originally defined, or additional resources can be allocated to allow the implementation of complementary features.

Done
Either the MVP disapproves the hypothesis or proves it was true, an epic is considered done once sufficient knowledge or value is achieved so that it is not a portfolio concern anymore.

How to describe an epic?

William Baxter, Lean & Agility-at-scale consultant, suggests an epic should at least include the following fields:

• Title
• The list of teams involved for its implementation
• Owner
• Description
• Dependencies
• Due date
• Type of epic (strategic, infrastructure, innovation, legal, etc.)
• Level of effort (or cost estimate)
• Business value
• And a field for some notes