It is said that improvement is eternal and infinite. It should be the duty of those working with Kanban to keep improving it with creativity and resourcefulness without allowing it to become fixed at any stage.
Program and Value Stream Kanban Abstract
SAFe supports the goal of continuous value delivery by implementing Kanban systems at all levels: Portfolio, Value Stream, Program, and Team. At the program and value stream levels, Features and Capabilities follow a common work flow pattern of exploration, refinement, prioritization, and implementing. The “pull” nature of the Kanban system allows programs to establish capacity management based on WIP limits and helps prevent the system from operating with large handoffs. Such continuous flow fosters collaboration and effective decision-making. Large initiatives, such as program and value stream Epics, are managed in a special section of the program and value stream Kanbans, resulting in features and capabilities intended to advance the Solution.
Program and Value Stream Kanban systems are aligned with the Program Increment (PI) cadence, allowing stakeholders and teams to elaborate, plan, and implement value in a routine, reliable manner, ensuring that none of the steps in the Kanban is overloaded or starving and that the solution is being reliably built in increments.
Together with the Portfolio Kanban, program and value stream Kanban systems constitute a SAFe enterprise content governance model that instantiates an economic decision-making framework and decentralization of control, vital to a fast, sustainable flow of value.
- Increase visibility into new work, and into the flow of work
- Ensure continuous refinement of new value definition and acceptance criteria
- Foster role collaboration about the new work across disciplines, functions, and levels
- Instantiate economic decision-making
- Establish connections among the Portfolio, value stream, and program levels
The Value Stream and Program Kanbans are connected to the Portfolio Kanban; together these three Kanbans constitute a content governance system that accounts for most of the significant decisions about what gets built. In a fully expanded case, portfolio Epics that have acquired sufficient readiness and have been approved for implementation get split into Value Stream epics and Capabilities that get loaded into the value stream Kanban. Capabilities and value stream epics, as they progress through the value stream Kanban, get split into Features and program epics and loaded into the program Kanban. Figure 1 illustrates such a case.
The optimum economic benefits and efficacy of the solutions in the portfolio are achieved by integrating centralized decision-making (vertical arrows) with the local context (horizontal arrows), which are those features and capabilities that arise directly from the value stream, ART, or Customer context. The connected Kanbans instantiate much of the economic decision-making framework and provide the foundation for a continuous feedback mechanism on decisions made.
The following sections explore program and value stream Kanbans in more detail.
A program Kanban system facilitates the flow of features and program epics. While all Kanban systems are purpose-built, a typical structure is illustrated in Figure 2.
The program Kanban consists of two main structural elements, the program epic section and the feature section, as described below.
Program Epic Section
The purpose of the program epic section of the program Kanban is to analyze and approve program epics and split them into features that will be further explored and implemented in the “downstream” feature section of the program Kanban (see Figure 2). This section is not always present in the program Kanban, depending on how frequently program epics occur in the local context of the program.
This part of the program Kanban system requires involvement of a higher level of stakeholders—typically at the value stream or portfolio level—to explore and approve program epics. The flow generally resembles the equivalent set of steps in the portfolio Kanban:
- All big initiatives are welcome in the Program Epic Funnel. There is no WIP limit at this step.
- The Program Epic Review step allows the assigned analysts to perform initial exploration of epics and rank them roughly, using WSJF, to determine which epics should move to the next step for deeper exploration.
- Program Epic Analysis provides the ability to explore the epic in more depth; refine size and WSJF compared to other epics in this step; consider solution alternatives; identify possible paths of the incremental implementation strategy; and determine the costs involved, technology and architectural enablement, infrastructure, etc. This information is captured in a lightweight business case. Based on that, stakeholders with sufficient content and budget authority consider approval of the epics. Approved epics are split into features and transitioned to a feature Kanban.
Similar to portfolio epics, program epics may require Epic Owners who will help with the definition, exploration, and implementation of an epic.
The purpose of this section of the program Kanban system is to facilitate readiness, prioritization, and implementation of features. Features may originate locally (either from program epics or introduced as individual features that don’t have a parent program epic) or come from the upstream Kanban. In either case, features enter the Feature Funnel.
The feature part of the program Kanban stays fully under the purview of local content authority: Product Management and System Architects. The following steps instantiate the feature section of the Agile Release Train (ART) Kanban:
- All new features are welcome in the Feature Funnel. These may include new functionality or enhancement of the existing system functions. New backlog items that enhance system qualities or produce architectural or infrastructure enablement also originate here.
- Features that align with the Vision and support strategic themes are moved to Feature Analysis for further exploration. This step requires refinement of the key attributes of a feature: business benefit, acceptance criteria, and WSJF. General sizing of features also occurs at this step, as features are estimated in normalized Story points. The purpose of such estimation is to support economic estimating and forecasting of value delivery over a longer period of time based on scope. Some features under analysis may require prototyping or other forms of exploration that involve Agile Teams. Typically such exploration work is included in the PI plan. The WIP limit at the analysis step is expressed based on overall availability of Product Management, other subject matter experts involved, and the capacity of teams dedicated to exploration activities.
- Highest-priority features that were sufficiently elaborated and approved by Product Management move to the next step—Program Backlog—where they are prioritized with WSJF relative to the rest of the backlog.
- At every PI boundary, the ART pulls the top features from the program backlog and moves them into the Implementing step. The transition is performed as a result of the PI Planning process, where selected features get broken down into stories and subsequently implemented by teams during the PI.
The program Kanban is managed by Product Management, who has content authority over business features, and System Architects, who support Enablers. They periodically involve external stakeholders with fiduciary responsibility and decision-making capacity to approve larger initiatives.
Value Stream Kanban
The value stream Kanban generally repeats the structure and flow of the program Kanban system, so it won’t be described further here. However, it operates with capabilities and value stream epics, respectively. The value stream Kanban is managed by the Solution Management team and supported by Solution Architects. Involvement of portfolio stakeholders is necessary to approve value stream epics.
Both program and value stream level Kanban systems require certain ceremonies that support the flow of value. Some of these serve a broader purpose, while others are specific to the Kanban system itself. Since value stream and program levels operate on a synchronous PI cadence, it is critical to align Kanban system activities to that cadence. Below are suggested ceremonies in the context of program and value stream Kanban systems. The Release Train Engineer and Value Stream Engineer typically facilitate these ceremonies at their respective levels.
Epic Specification Workshop
Structured similarly to the specification workshop at the portfolio level, the epic specification workshop involves analysts and stakeholders who have authority over program and value stream epics. During the workshop, some epics can be pulled from funnel to review, others from review to analysis. For still others, a go or no-go decision will be made, followed by resultant features and capabilities being transitioned to the “downstream” part of the Kanban.
Program/Value Stream Backlog Refinement
The goal of this workshop, which typically involves content and technical authority at the relevant level, is to build the backlog of features or capabilities, respectively. Sizing and elaboration of business benefits and acceptance criteria are performed at this time. Rough WSJF prioritization sequences the features and capabilities that can be pulled into the backlog.
In the general case, PI Planning begins with a Pre-PI Planning session at the value stream level, where capabilities from the value stream Kanban are split into features and fed into the program Kanban systems for each train in the value stream. The input to this session is the set of top capabilities from the Value Stream Backlog. The session involves both Solution and Product Management. Each Product Manager will bring the resultant features to their program Kanban system and place them in the “feature funnel” step, if more elaboration is needed. The features will move through the Kanban system, and those that get through refinement will be pulled by the trains into their two-day PI planning session. The aggregated results of these sessions will be brought back up to the value stream level (Post-PI Planning) for better understanding of which capabilities made it into the implementation.
Last update: 20 April 2016