Innovation comes from the producer, not the customer.
You may be interested—W. Edwards Deming, Paraphrased from Out of the Crisis [1]
You are viewing: Who Is Responsible For Managing The Portfolio Kanban
The Portfolio Backlog is a Kanban system that is used to capture and manage the business and enabler epics intended to create and evolve the portfolio’s products, services, and solutions.
Lean Portfolio Management (LPM) is responsible for developing, maintaining, and prioritizing the Portfolio backlog. They actively collaborate with stakeholders, including Business Owners (many of whom are part of LPM), Product and Solution Management, Epic Owners, Enterprise Architects, and others, to discover the epics needed to advance the portfolio’s solutions.
Portfolio Epics are large (and typically cross-cutting initiatives) managed through the Portfolio Kanban. Since more effort and capacity are required as the epic travels from the left to the right of the Kanban, LPM carefully decides which ones will proceed to each subsequent step or be removed altogether.
Building and Refining the Backlog
LPM applies a flow-based approach to build and refine the backlog, ensuring portfolio epics are ready for implementation with an appropriate level of discovery and risk.
Refining the portfolio backlog to ensure readiness often involves the following activities:
- Reviewing new epics and determining their alignment with the portfolio’s strategic themes and vision
- Evaluating the Epic Hypothesis Statement to decide whether it warrants assignment to an Epic Owner
- Prioritizing the backlog using Weighted Shortest Job First (WSJF) and other factors in collaboration with Business Owners, Enterprise Architects, Product Management, and other stakeholders
Backlog refinement activities often occur during the Portfolio Sync and the Strategic Portfolio Review events. LPM and its stakeholders add new backlog items to the Funnel, update priorities, and remove less promising epics. A well-maintained backlog is a prerequisite for successful portfolio management.
The Portfolio Kanban system visualizes and facilitates the flow of business epics and enablers from idea through implementation.
Portfolio epics are made visible, developed, and managed through the Portfolio Kanban system, where they proceed through various process states until they are approved or rejected. Before being committed to implementation, epics require analysis and approval. Epic Owners take responsibility for the essential collaborations needed for this task, while Enterprise Architects typically guide the enabler epics that support the technical considerations for business epics.
Many companies struggle with innovation because they do not actively manage their portfolio with enough rigor or discipline, allowing less critical efforts to continue while starving or delaying those with more potential. Simply picking amongst the best big ideas will not advance the portfolio from its current state to a more promising and better future state. It requires a purposeful journey where LPM and its stakeholders identify specific epics to achieve the portfolio’s Vision.
The portfolio Kanban helps align strategy and execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (epics) for a SAFe portfolio. LPM is responsible for the Kanban portfolio, which is often used during the strategic portfolio review and portfolio sync events to manage and monitor the flow of epics.
While opportunistic epics are welcome, LPM has a fiduciary responsibility to facilitate the flow of epics best aligned with the portfolio’s strategic themes, vision, and economic framework. Achieving a better future state requires the Development Value Streams to adopt a ‘one-portfolio’ mindset, where they cooperate to achieve the portfolio’s higher-level objectives and the broader aim of the enterprise.
Read more : Who is Mackenzie Phillips’ Son: Meet Shane Barakan
Figure 1 illustrates an epic’s process from the Funnel to completion, where the Epic Owner coordinates its advancement through the portfolio Kanban. Only the Reviewing, Analyzing, and Ready states have explicit WIP limits. The MVP sub-state has an implicit WIP limit, the available capacity of trains, and the value streams’ budget.
The Kanban’s design should evolve to match the needs of a specific portfolio and reflect continuous improvements to the process. 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.
Each example portfolio state is described further in the following sections.
Funnel
The Funnel is used to intake all significant business and technology ideas for a specific portfolio. These ideas may originate as strategic concerns, arise from Agile Teams or ARTs, 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.
Epics are initially described in the Epic Hypothesis Statement (see Epic article). The Funnel is not WIP limited as these epics are simply ideas that may deserve additional consideration. If an initial review of an idea is not likely to exceed the epic threshold guardrail or be a portfolio concern, it moves to the ART or Solution Train Kanban. While they can arise from any source, Figure 2 illustrates how epics typically flow into the Funnel:
- Maintaining the Portfolio Vision and Roadmap identifies new initiatives that feed directly into the portfolio Kanban. These initiatives may include updates from the Enterprise strategy or supporting other portfolios.
- The Continuous Exploration process discovers user and market needs and may result in identifying epics.
Reviewing
Since epics are some of the most significant portfolio investments, an Epic Owner is needed to sponsor the epic and define its intent. When an Epic Owner is available, they pull the epic into this state, working with relevant stakeholders to refine and further elaborate the Epic Hypothesis Statement.
A WIP limit for this state is typically specified. Moreover, the lack of an Epic Owner available to do the work can serve as an implicit WIP limit. A WSJF estimate relative to other items in the reviewing state is established based on preliminary sizing and cost estimates. Suppose the epic does not appear sufficiently viable or aligned with the portfolio’s strategic themes or other guardrails. In that case, it moves to the Done state, which frees capacity for more promising alternatives.
Analyzing
When the Epic Owner has the capacity and room within the WIP limit, epics with high potential are pulled into the Analyzing state. Epics that make it here deserve more rigorous analysis and further investment. This state typically requires active collaboration among the following roles:
- Business Owners
- Enterprise Architects and System and Solution Architects
- Product and Solution Management
- Agile Teams
During the analysis state, the following activities typically occur:
- Identification and review of solution alternatives
- Defining the MVP
- Establishing refined cost estimates for the MVP and its full anticipated scope
- Creating the Lean Business Case
- Small research spikes to demonstrate potential technical and business viability
- Initial customer validation
- Updating WSJF relative 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 epic’s analysis and eventual implementation consume precious capacity, approval to move into the next state is more rigorous. WSJF is one factor, but many additional considerations, such as the Lean Business Case, may also be applied.
LPM uses the Lean Business Case during the portfolio sync 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.
Ready
Epics in the analyzing state with the highest WSJF are pulled into the next state, Ready, as soon as space is available. This state is a low-cost wait state where epics are periodically reviewed and prioritized by updating WSJF and other relevant factors.
Implementing
Since many companies will generate more good ideas than they can fund, LPM and participants from different Value Streams collaboratively determine which epics should be implemented based on Participatory Budgeting (PB) or a similar process. The results of the PB event provide feedback to help LPM decide how to adjust value stream budgets to support the implementation of the most beneficial business and enabler epics.
Read more : Who Makes Navos Radio
The implementation of epics also includes considerations for sequencing work, sizing, and ranking the epics relative to each other, typically by one final Weighted Shortest Job First (WSJF) prioritization. Adjustments to epic priority from WSJF may be necessary to stay within the Lean budget guardrails, such as capacity allocation, investment horizons, and other factors. LPM should have a good understanding of available ART capacity since the job duration used by WSJF may be affected by implementation capacity.
The Epic Owner works with various stakeholders to split epics into Features and Capabilities. The responsible ARTs and Solution Trains pull the work into their respective backlogs, as illustrated in Figure 3.
When ready for implementation, features and capabilities are presented at the relevant PI Planning events to begin the development of the epic’s MVP. LPM evaluates the MVP’s progress based on leading indicators, Value Stream KPIs, and demos.
The implementation step has two sub-states, MVP and Persevere. They are described in the following sections:
MVP
When sufficient capacity from one or more ARTs is available, the epics with the highest WSJF advance to the MVP state. Here, the Epic Owner works with the Agile Teams to begin the activities needed to develop the MVP and evaluate its business outcome hypothesis. Work on the MVP continues until the money allocated for the MVP has been spent or the hypothesis can be evaluated.
If the value stream runs out of money to implement the MVP and the need for the epic still exists, a new one can be proposed and placed in the Funnel. The original epic moves to Done. Of course, LPM can adapt this rule (and any others) to meet the needs of their organization.
Persevere
If the hypothesis is proven true, the epic advances to the Persevere state, and teams will continue to implement additional features and capabilities. ARTs manage the additional investment via ongoing feature prioritization in the ART Backlog 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 a higher priority. Epic Owners remain available to assist ARTs and Solution Trains responsible for implementation.
Done
An epic is considered Done when sufficient knowledge or value is achieved, or it is no longer a portfolio concern. Completing the fully envisioned scope from the Lean business case is not a criterion. Instead, the epic is Done if:
- It is ejected from the portfolio Kanban by LPM in any of the earlier states
- The hypothesis is proven, and LPM has determined that additional portfolio governance is no longer required
If the hypothesis is proven, work on the epic may continue by various ARTs responsible for its implementation. The Epic Owner may need to provide ongoing guidance and follow-up. Since the epic is no longer a portfolio concern, leading indicators, value stream KPIs, and Guardrails are used to keep LPM informed of progress.
Learn More
[1] Deming, W. Edwards. Out of the Crisis. The MIT Press, 2018.
Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.
Last update: 6 September 2023
Source: https://t-tees.com
Category: WHO
