The only way you can create excess inventory is by having excess manpower.
—Eli Goldratt

Or perhaps overspecialization?
—SAFe Authors

Team Kanban

Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work-In-Process (WIP) limits, measuring throughput, and continuously improving their process.

Kanban systems are used—but for somewhat different purposes—at the Portfolio, Large Solution, Program, and Team Levels of SAFe. This article describes Team Kanban.

SAFe teams have a choice of Agile methods. Most use Scrum, a lightweight, effective, and popular method for managing work. Teams that develop new code also apply XP practices to bring focus to software engineering and code quality. Some teams, however—particularly System Teams, Operations, and maintenance teams—choose to apply Kanban as their primary method. In these contexts, the rapid-fire nature of the work, the fast-changing priorities, and the lower value of planning activities for the next Iteration all lead them to this choice. This article will describe a Kanban system well suited to SAFe Agile Teams. However, these teams are “on the train,” and certain rules must apply.


Generally, Kanban is described as a pull system. Teams “pull” work when they know they have capacity for it, rather than having scope “pushed” on them. This article describes Team Kanban, a method that helps teams facilitate the flow of value by visualizing workflow and WIP limits, measuring throughput, and continuously improving the process.

A Kanban system is made up of workflow steps. Most steps have WIP limits, which a work item can be pulled into only when the number of items at that step is lower than the WIP limit. A few steps (typically beginning and end steps) are not limited. WIP limits are defined and adjusted by the team, allowing it to adapt quickly to the variations in flow characteristics of complex systems development. In SAFe, Team Kanban is applied together with the cadence and synchronization requirements of the Agile Release Train (ART). This facilitates alignment, dependency management, and fast integration-based learning cycles. These provide the objective evidence needed to advance the larger Solution.

Kanban Description

Kanban, which means “visual signal,” is a method for visualizing and managing work. While there are many interpretations of how to apply Kanban in development, most would agree that the primary aspects include the following:

  • The system contains a series of defined steps that the work moves through.
  • All work is visualized, and the progress of individual items is tracked.
  • Teams agree on specific WIP limits for each step and change them when necessary to improve flow.
  • Teams adopt specific policies for how work is managed.
  • Flow is measured. Work items are tracked from the time they enter the system to the time they leave, providing continuous indicators of the amount of work in process and the current lead time. In other words, how long, on average, it takes an item to get through the system.

Prioritization is done by assigning a class of service, based on Cost of Delay (CoD).

Visualizing Flow and Limiting WIP

To get started, teams typically build an approximation of their current process flow and define some initial WIP limits. Figure 1 shows an example of one team’s initial Kanban board, which captures their current work flow steps: analyze – review – build – integrate – test.

Figure 1. One team’s initial Kanban board

In Figure 1, the team has also decided to create two buffers (see, ‘Ready’ above) to better manage flow variability. One is in front of the “Review” step, which might require external subject matter experts (Product Management or others), whose availability may be limited and uneven. The other buffer is in front of ‘Integrate and Test,’ which, in their case, requires the use of shared test fixtures and resources. Since integration and testing are performed by the same people on the same infrastructure, the two steps are treated as a single step. Also, to justify the transaction cost, the team allows reasonably higher WIP limits for the “Review” and “Integrate and Test” steps.

A team’s Kanban board evolves iteratively. After defining the initial process and WIP limits, and executing for a while, the team’s bottlenecks should surface. If not, the team refines the steps or further reduces some WIP limits until it becomes obvious if a step is ‘starving’ or is too full. This helps the team adjust to optimize their flow. As the assumptions are validated, WIP limits are adjusted and steps may be merged, split, or redefined.

Measuring Flow

In order to understand and improve their flow and process, Kanban teams use objective measures, including average lead time, WIP, and throughput. One common tool is a Cumulative Flow Diagram (CFD), as illustrated in Figure 2.

Figure 2. Cumulative Flow Diagram (CFD) shows how lead time and WIP evolve over time

Each backlog item is date stamped, both when it enters the workflow (pulled from the team backlog to begin implementation), and when it is completed. The arrival curve shows the rate at which backlog items are pulled into work. The departure curve shows when they have been accepted. The x-axis shows the average lead time—how long it takes, on average, for an item to get through the system. The y-axis shows the WIP—the average number of items in the system at any point in time.

Throughput—the number of stories completed per a period of time—represents another critical metric. Since Kanban teams in SAFe operate on an Iteration cadence, they measure throughput in number of Stories per iteration.

The CFD provides the data for the team to be able to calculate their current iteration throughput. To arrive at the average number of stories processed per day, the team divides the average WIP by the average lead time. Then they multiply by 14, which is the number of days in the iteration. This provides the iteration average throughput by number of stories per iteration, which helps with planning. (This will also be important in calculating ‘derived velocity,’ as described later in this article.)

The CFD also provides an important visualization of significant flow variations, which may be a result of systemic internal impediments the team is not aware of, or external forces that impede the flow. The CFD is an excellent example of an objective measure that facilitates Relentless Improvement for Kanban teams.

Improving Flow with Classes of Service

In addition, teams need to be able to manage dependencies as well as ensure alignment with Milestones. Kanban uses the concept of classes of service to help teams optimize the execution of their backlog items. Classes of service help differentiate backlog items based on their Cost of Delay (CoD). Each class of service has a specific execution policy that the team agrees to follow. For example:

  • Standard – Most backlog items should fall in the normal case—new development, which is not specifically date dependent. The CoD is linear for standard items, meaning that value cannot be achieved until delivery occurs, but there’s no fixed-date requirement.
  • Fixed date – Fixed-date items represent milestones and dependencies with a predetermined date. The CoD is nonlinear. These items are pulled into development when necessary to be finished on time. Some may require additional analysis to refine the expected lead time; some need to be reclassified as ‘expedite’ if the team falls behind.
  • Expedite – An ‘expedite’ backlog item has an unacceptable CoD and therefore requires immediate attention. It can be pulled even in violation of current WIP limits. Typically, there can be only one “expedite” item in the system at a time, and teams may set a policy to swarm on that item to make sure it moves through the system rapidly.

If teams find that many items require expediting, then the system may be overloaded. Either demand exceeds capacity, or the input process could be undisciplined. Whatever the case, the process needs to be adjusted.

As illustrated in Figure 3, classes of service are typically visualized as “swim lanes.”

Figure 3. Classes of Service on the Kanban board

In addition, the teams may reserve specific colors for different types of backlog items (see PI Planning), such as ‘new functionality’, ‘research spike’, ‘modeling’, etc. This adds clarity to the work being performed.

Close attention to the structure of flow provides Kanban teams with improvement opportunities that otherwise would pass unnoticed. For example, changes in the CFD may suggest increasing average WIP (which will cause an increase in lead time). While this may just be a symptom of a deeper problem, the team now has a way of spotting it. Regular reflection and adaptation of the process are necessary to realize the benefit of high visibility of flow.

The SAFe Kanban Team Is on the Train

SAFe Kanban teams operate in a broader context, building a solution that requires multiple Agile Teams and may even span multiple Agile Release Trains (ARTs). To accomplish this, the team needs to adhere to specific SAFe rules in addition to the regular Kanban guidelines. The rules are that the teams plan together, integrate and demo together, and learn together, as is described in more detail in the Agile Teams article. Planning together is one element that warrants further discussion, as described below.

Estimating Work

Generally, Kanban teams don’t invest as much time in estimating or tasking as Scrum teams do. Instead, they take a look at the work needed, split the bigger items where necessary, and push the resulting stories to completion, mostly without much concern for their size. However, SAFe teams must be able to estimate the demand against the capacity for PI planning; and they also help estimate larger backlog items. Also, in order to forecast, there must be an understanding of the teams’ velocity in a manner that’s consistent the other teams on the train, and the total ART velocity.

Establish a Common Starting Point for Estimation

Initially, a new Kanban team has no knowledge of its throughput, as that is a trailing measure based on history. To get started, SAFe Kanban teams need a way to estimate work, often beginning with the first PI planning session. In a manner consistent with Scrum teams, estimation of initial capacity begins with normalized estimating (as described in Iteration Planning). Kanban teams then add their estimated stories into iterations, just as the Scrum teams do. Their starting capacity is their assumed velocity, at least for the first Program Increment (PI).

Calculating Derived Velocity

After this starting point, Kanban teams can use their CFD to calculate their actual throughput in stories per iteration. Or they can simply count and average them. Kanban teams then calculate their ‘derived velocity’ by multiplying the throughput by an average story size (typically three to five points). In this way, both SAFe Scrum and Kanban teams can participate in the larger Economic Framework, which, in turn, provides the primary economic context for the Portfolio.

Estimating Larger Work Items

At the Portfolio and Large Solution Levels, it is often necessary to estimate larger work items to determine their potential economic viability (Epics and Capabilities). In addition, developing Program Roadmaps requires:

  1. A knowledge of estimating (how big is the item)
  2. ART velocity (how much capacity does the ART have to do it)

In order to do this, Kanban teams break larger initiatives into stories for estimating, just as the Scrum teams do. This provides the finer resolution needed to estimate larger items. Stories are then estimated in normalized story points. This provides the ability for the Enterprise to aggregate estimates from various teams—and types of teams—without excessive debate.

Learn More

[1] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.

[2] Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Programmers, 2012.

Last update: 28 September, 2017