Use Flow-Based Boards (Kanban)

Board Expedite image

Kanban usually means a board for visualizing the flow of work. It can also mean the cards that populate the board. The Kanban method is a set of principles and practices for managing and improving the flow of work.

If you use the Kanban method, you will always have a board. People use Kanban boards even if they are not following the rules of Kanban to help understand and communicate the progression of work on a project or other endeavor.

Simple Kanban image

This is a simple Kanban. Work items on cards flow from left to right through columns or states.

The objective of a Kanban system is the smooth flow of work from start to completion without unnecessary slowdown or stoppage.

Kanban teams limit the number of items they work on at one time (WIP) in order to reduce the cycle time it takes to get individual things to completion.

Kanban topics include:

Core Practices of Kanban

These are the fundamental aspects of an operating Kanban system. It often makes sense to introduce these sequentially to a team.

  1. Visualize flow. This may start with a diagram of how work gets done in a team: the steps, hand-offs, decisions, work queues, demand patterns, and so on. Ultimately, it takes the form of a Kanban board, either in an electronic tool or with sticky notes on a whiteboard.
    Simple work flow image
    This is a simple work flow...
    Simple work flow translated to kanban image
    ...and how it might be translated to a Kanban board.
  2. Limit WIP. Kanban teams set limits for the number of work items in each column on the board. WIP limits are meant to represent the capacity of the team, and it is normal for them to evolve as the team learns more about what works best to balance smooth flow and low cycle time.
    Done column no limit image
    The Done column does not have a limit, but most or all of the others do.
  3. Make management policies explicit. Kanban teams define simple rules for how work flows for different types of work items, when to pull an item into the next state, how to flag and manage blocked items. These are often posted near the board. They evolve as the team improves.
    Kanban policies for each state image
    It is common to have policies for each state, as well as overall policies or working agreements inside the team and with stakeholders.
  4. Manage flow. Teams use data they gather on average cycle time and other metrics, along with information from the current state of work on the board, to manage the work in a way that delivers the maximum value the fastest.
    Metrics CycleTime image
    Teams strive to balance minimum cycle time with maximum throughput.
  5. Improve collaboratively. A Kanban system highlights the most critical opportunities for improvement. Teams work on these as a group and apply problem-solving methods to get to causes and to hypothesize and test solutions.
    Kanban Blocked Red image
    This board has items blocked (shown with red flags). Column C has no work, and A is stuck because both A and B are at their WIP limit.


Teams using Kanban pay close attention to bottlenecks. They work quickly to remove the bottleneck and get work flowing again, and will look for ways to prevent the bottleneck from occurring again in the future. This is at the heart of continually improving the overall flow of work, which is a fundamental concept in Kanban.

Kanban Bottleneck Column image

This is a sample of a board with a severe bottleneck in column B, which is over limit. Column A is blocked and C is needs work. WIP limits are in red.

Kanban Boards

Most boards start with Ready and end with Done. Ready means work is accepted into the team's flow. This column is a queue—no work is done while a card is in this state. Each state indicates the principal type of work going on while the card is in the column. But the team could, for example, be doing early testing while the card is in Build.

Board-Kanban Basic image


When a team needs to deal with an emergency or critical work that suspends other cards, and expedite process may be used. When an expedited card is on the board, the team may ignore WIP limits until the card work is complete. We recommend setting up an expedite agreement such that only one card may have this status at any time.

In CA Agile Central, use card coloring to indicate an expedited request. Agree on a color beforehand, and do not use that color on other cards.


Kanban only defines a few specific metrics. The purpose of this data is to aid the team in making decisions to optimize flow and to drive and measure improvement.

Cycle time (CT): This is the most fundamental Kanban metric. It is the time an item spends on the board, from Ready to Done. It is not a measure of effort, but elapsed time in days. Reducing average CT is often a primary objective of Kanban teams.

Metrics Cycle Time image

CT confidence levels: A team can apply simple statistics to the cycle times of items and determine confidence levels for how long new work is likely to take, and use this to set expectations with stakeholders.

Metrics CT Confidence Levels image

In this example, 75% of the team's work items get done in around 8 days, and 95% in around 12 days.

Throughput (TP): This is the number of items that the team reliably completes in some specific span of time. TP is the main capacity metric.

Little's Law: CT and TP are related by a simple formula known as Little's Law, which states that TP = WIP/CT. From this it is clear that, for a given amount of WIP, throughput will increase if cycle time can be reduced. (Source: Little's Law is more formally stated as L=λW.)

Due Date Performance: If some work items have specific due dates (and there are policies to govern this), then it is useful to have a metric that tracks the number of days over or under for each item. The objective is to get done as close to the due date as possible.

Blocks: A record of blocks and their duration helps describe how the system is improving over time. Reducing blocks naturally leads to lower CT.

Quality: Most teams agree that it is fundamental to have a metric that tracks quality over time. This is often something like initial or escaped defects per time period. Since increased WIP frequently correlates to lower quality, this an important aspect to measure.


Kanban was developed by adapting principles from Lean manufacturing—along with other disciplines—and shares many of its core concepts. These include:

  • System thinking: Maintaining a focus that includes the entire delivery system and how events and changes impact the whole.
  • Learning: Emphasizing the need to collect, interpret and apply data, experiences, and understanding to drive improvement of the system.
  • Flow: Promoting and maintaining the smooth progression of work through a system, minimizing the wastes of rework, stoppages, bottlenecks, and queues.
  • Pull: Drawing work into the overall system—or into a specific state—only when capacity becomes available, rather than pushing work in based on a schedule or outside decision.
  • Slack: Reserving capacity to respond to normal variations and unexpected conditions, rather than attempting to maximize utilization of individuals.
  • Swarm: Quickly handling work problems with all needed resources to promote flow.

Additional Concepts

The topics below introduce somewhat more advanced Kanban concepts. A team may want to delay detailed consideration of these until it has experience running its Kanban system and has collected sufficient data to inform further decisions.

Work Item Types

Most teams will try to understand the demand patterns of their work and to identify of the types of items they work on. This may be as simple as classifying them into S‐M‐L sizes, or creating whatever divisions are helpful. Metrics can then be filtered based on these types, and this information can help to substantially improve the team's overall predictability.

Classes of Service

With sufficient data and experience, a team can potentially identify a limited number of work item types and then develop policies to optimize the flow of work and value delivered. Policies might include guidance on prioritization and pulling of work, and triggers for tackling problem situations.

Teams develop classes of service that address their specific needs. David Anderson has suggested four classes of service with an intention of improving stakeholder flexibility and satisfaction:

  • Expedite
  • Fixed Delivery Date: Items with a valid reason to meet a specific date, such as a contractual or regulatory obligation. Kanban discourages assigning dates arbitrarily.
  • Standard: The common class of items with normal urgency.
  • Intangible: Lower priority items that do not have a significant (or urgent) cost of delay.


Based on information on cycle times and confidence levels and the policies associated with different classes of service, it is possible to create Service Level Agreements (SLAs) with stakeholders. SLAs address stakeholder expectations of how long a work item can be expected to take to complete, with a certain level of confidence, based on the team's performance in delivering similar items in the past. SLAs are not promises to deliver in a specified time, leading some to suggest Service Level Expectations as a better name.

Scaling Kanban

Kanban is evolving rapidly and finding ways to manage larger and more complex delivery contexts. Multi-level systems can help teams of teams manage and improve their work.

Kanban is also being applied to wider aspects of work management, including discovery and decision processes for managing programs and portfolios, and for providing rolled-up views of complex delivery scenarios.

Additional Reading

  • Implementing Lean Software Development, Mary and Tom Poppendieck, Addison-Wesley, 2007.
  • Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson, Blue Hole Press, 2010.
  • Lean from the Trenches, Henrik Kniberg, Pragmatic Programmers, 2011.
  • Priming Kanban, Jesper Boeg, Trifork A/S, 2011.
  • Scrumban, Corey Ladas, Modus Cooperandi Press, 2008.
  • Theory of Constraints, Eliyahu Goldratt, North River, 1999.


Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.