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.

—Taiichi Ohno

SAFe Team Kanban

Definition: SAFe Team Kanban is an Agile method used by teams within an ART to continuously deliver value. SAFe Kanban teams apply a flow-based process to their daily work and operate within the ART iteration cadence.

Kanban teams apply a flow-based process to their daily work and operate within the Agile Release Train (ART) iteration cadence. The Kanban method provides a strategy for optimizing the flow of value using a visual, pull-based system instead of work being pushed to or by the team. “Kanban comprises the following three practices working in tandem [1]:

• Defining and visualizing a workflow
• Actively managing items in a workflow
• Improving a workflow.”

In SAFe, Kanban systems manage the backlog and flow of work at every level of the Framework. Each reflects a team’s unique process for delivering value and its current workflow and capacity.

Details

Most Agile Teams use SAFe Scrum as their primary method to deliver value. However, some teams have a rapid and uneven arrival of work and fast-changing priorities that lowers the value of the time investment in iteration planning. In these cases, teams often choose SAFe Team Kanban instead. For example, System Teams, operations, support, hardware, and various business teams often find SAFe Team Kanban a good choice for their context.

In addition, the level of visibility and flow that Kanban provides causes it to spread to different parts of the organization. Today, many organizations adopt Kanban to help embrace Lean-Agile Principles across all aspects of business, from marketing to finance, human resources to legal, security to compliance, operations to Agile Teams, and more.

Like all SAFe Agile Teams, Kanban teams determine how they manage their work. They create and refine backlog items—typically expressed as Stories with acceptance criteria—to define and achieve their Team PI Objectives. They then build, integrate, test, validate, and deploy the new functionality, ensuring Built-in Quality.

Since Kanban teams typically have all the roles and skills needed to develop and deliver increments of value, they operate with the minimum possible constraints and dependencies with other teams. A self-managed and cross-functional Kanban team creates a more enjoyable, fun, and productive work environment with constant communication, constructive conflict, and dynamic interaction.

The SAFe Team Kanban Board

A Kanban system includes a ‘Kanban board’ used to visualize and manage the work flowing through the system. The standard elements of a Kanban board are shown in Figure 1.

• Work in Process (WIP) limits set the maximum number of items for an individual workflow state.
• Columns represent a series of steps, each representing an activity that collectively defines the team’s workflow.
• Cards represent work items, such as user stories and enablers.
• Swim lanes group and highlight related work items to define the team’s workflow. Typical use of swim lanes includes separating work for different classes of service, such as lanes for expediting, individual workflows, cross-team dependencies, features, and more.
• Policies specify how work is managed, such as exit or entry criteria for moving a work item from one state to another or defining the rules for service classes.

See Figure 4 for an example of a more fully elaborated Team Kanban system with columns (steps) used by an actual team.

The SAFe Team Kanban Method

While Kanban guides managing work in a flow-based system, it is not explicit concerning the roles, responsibilities, and events that teams use to apply Kanban as their Agile practice. SAFe addresses this as illustrated in Figure 2 below. Each element of the SAFe Team Kanban method is described in the following sections.

Team Backlog

The Team Backlog contains all the upcoming work needed to advance the solution. Teams continually refine the backlog to ensure it has some stories ready for implementation without significant risk or surprise.

During PI Planning, teams decompose Features into stories in the backlog and establish their PI Objectives. The team’s local concerns (other new functionality, defects, refactors, tech debt, and maintenance) are also in the backlog. These stories reload the team backlog for the upcoming PI. But since PI planning is high level, teams will likely need to adjust their plans as stories are refined, acceptance criteria are established, and other new facts emerge. Moreover, feedback from previous increments, the System Demo, and other groups with whom they collaborate provide rolling wave updates to the backlog and flow of work.

Plan

Although the flow of work is continuous, planning is valued in Agile, and Kanban teams are no exception. Many Kanban teams plan weekly to coordinate their work, replenish stories in the backlog, and address dependencies and fixed date commitments. Some Kanban teams find it convenient to align their weekly planning with the iteration cadence of the ART. Once complete, the team records the planned work in a visible place, such as a physical Kanban board or Agile project management tooling. A weekly planning time box of 60-90 minutes is typical.

As part of planning, SAFe Kanban teams often establish Iteration goals, which provide Agile Teams, Agile Release Train (ART) stakeholders, and management with a shared language for maintaining alignment, managing dependencies, and making necessary adjustments during the execution of the PI.

Kanban teams continually replenish the backlog and identify any stories that need to be completed in a specific timebox (fixed date or expedited class of service). They also ensure a sufficient amount of prioritized backlog items exists for at least one or two iterations. That’s their plan and commitment to the business.

Deliver

In SAFe, teams apply Kanban within the development cadence and synchronization requirements of the Agile Release Train (ART). They, like others, Release on Demand. This cadence and synchronization facilitate alignment, dependency management, and fast integrated learning cycles (SAFe Principle #4).

The Kanban system visualizes all active and pending work, workflow states, and WIP limits. A work item can be pulled into a state only when the number of items currently in that step is below the WIP limit. A few activities (typically beginning and end) may not be limited. WIP limits are defined and adjusted by the team, allowing it to adapt quickly to the variations in the flow of complex system development.

Team Sync

In addition to the weekly planning meeting, Kanban teams coordinate their work throughout the week. They decide if these syncs are cadence-based or ad hoc. The tempo and timing can vary significantly based on stages of development. A typical pattern is holding a team sync weekly around midweek. Kanban teams typically discuss the following kinds of topics during this time:

• Review how work is flowing and remove impediments
• Peer review of WIP and adjust upcoming planned work
• Review and accept stories
• Discuss improvements to the team’s process
• Planning for the system demos that occur throughout the PI
• Monitoring fix-date commitments and flow metrics

In a flow-based system, the team can release work into later stages without formal signoffs or approvals, subject to the team’s policies. Therefore pairing and swarming are routine and informal to help better ensure built-in quality before deployment.

System Demos

Like all SAFe Agile Teams, Kanban teams participate in the ART’s system demos, representing another form of syncing within the team and across the ART. This synchronization ensures the integration of the team’s work into the solution, including demoing progress. It also fosters collaboration with other groups and stakeholders to assess the solution, making mid-course corrections as necessary.

Increment

Kanban teams deliver small increments of value throughout the PI, representing how new functionality evolves. Each increment is additive and is a working, tested, and functional solution element.

Retrospective

Kanban teams periodically reflect and identify new ideas to improve their process. These improvements often result in updates to the Kanban board to capture the revised process. Retrospectives help instill the concept of relentless improvement—one of the SAFe Core Values, ensuring that the team continually improves. While optional, teams may conduct a retrospective, every iteration aligned with the ART or at least once per PI, typically just before the ART’s Inspect & Adapt (I&A) event. In this way, the knowledge from their team retrospective can inform the problem-solving part of the I&A.

Kanban Roles

While Kanban is generally less specific on team roles, SAFe applies the two Scrum special team roles— the Product Owner and the Scrum Master/Team Coach. These roles have emerged in practice as equally helpful to Agile Teams applying SAFe Team Kanban (Figure 3).

As with Scrum, the Product Owner is a member of the Agile Team responsible for maximizing the value delivered by the team and ensuring that the Team Backlog is aligned with customer and stakeholder needs. As a member of the extended Product Management function, the PO is the team’s primary customer advocate and link to business and technology strategy. This role enables the team to balance the needs of multiple stakeholders while continuously evolving the Solution. They serve as the Kanban process intake owner and prioritize the team backlog to help ensure the team is building the right thing.

The SAFe Scrum Master/Team Coach (SM/TC) is a servant leader and coach for an Agile Team. They help educate the team in Kanban, Built-in-Quality, and SAFe Scrum, ensuring that the agreed Agile processes are followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

Establishing the Team Kanban

Effective Kanban systems are established based on the needs of each Agile Team and the type of work performed (for example, software development, hardware, marketing). Establishing the Kanban system typically involves the entire Agile Team with the guidance and facilitation of an experienced coach. The SAFe extended guidance article, Applying Kanban in SAFe, describes establishing a Kanban system and how they connect in SAFe. Figure 4 illustrates an example of a more fully elaborated Team Kanban system.

Improving and Measuring Flow

Measuring Flow

Kanban systems provide a rich data set that can identify bottlenecks and improve flow. Several standard metrics can measure different aspects of flow. These include Flow Distribution, Flow Velocity, Flow Time, Flow Load, Flow Efficiency, and Flow Predictability. See the Measure and Grow and Team Flow articles for information on measuring flow.

Optimizing Flow

A team’s Kanban board should evolve iteratively and continuously adapt to fit the team’s needs. After defining the initial process and WIP limits and running the system, bottlenecks should become visible and can be addressed. Other changes to optimize flow might include adding, merging, or splitting steps, adding buffers, or redefining workflow states.

Estimating Work

Due to the rapidly changing nature of work items, there is typically less emphasis on estimating stories than in Scrum. Instead, Kanban teams look at the work needed, right-size it by splitting large items where necessary, and pull the resulting work through the Kanban system to completion.

However, SAFe teams still estimate the demand for work against their capacity during PI planning and help contribute to estimates for cross-team backlog items (for example, features and epics).

---

Learn More

[1] The Kanban Guide. https://prokanban.org/the-kanban-guide/

[2] Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Sequim, Washington: Blue Hole Press, 2010.

Last update: 14 March 2023