10 Kanban Board Examples

1. Copy wisely. The Kanban board examples included in this list were built to meet the needs of specific teams. Our goal for sharing them is not to give you a “cheat sheet,” but to provide inspiration to help you create a Kanban board that matches your own team’s unique process.
2. Think outside team lines. These Kanban board examples are geared to specific teams and types of work, but they aren’t meant to be exclusive to those uses. So if you’re on a development team but see something you like on one of the IT operations team boards, try it (and vice versa). Many Kanban best practices are transferable from one team type to another, and can also be applied at various levels within the organization (not just in teams).
3. Start with (or get back to) the basics. Whether it’s your first board or your 100th, it can be helpful to start from scratch with a clean, new board so that it reflects the reality of your current practices.

Software development teams were some of the earliest adopters of the Kanban method. Here are three examples illustrating how development teams might use Kanban boards to manage parallel processes, reinforce a pull system using “Ready” queues, and implement WIP limits.

Visualizing parallel processes

Within any given team, there can be several processes working in parallel that are closely related, but distinct enough to require their own workflows. For example, a development team might need to track feature development and testing, as pictured in this example.

Rather than oversimplifying the process steps to meet the needs of both processes with a single workflow, teams can design their boards to track both processes in parallel by using horizontal swimlanes.

Building their Kanban boards this way means that teams can respect parallel processes among developers without losing visibility of the team’s work as a whole.

Reinforcing a pull system with ready queues

Implementing a pull system, a key part of a mature Kanban practice, requires team members to work together to ensure that work is only being moved when people are actually ready to begin working on it.

Problems often arise when teams have to hand off work from one person to another. For example, if the team members responsible for the “Develop” step are different than those responsible for the “Test” step. If the “Develop” step is completed for any given work item, the natural inclination is to move it to the next step of the process. But if the tester does not have capacity to begin work on that work item, the board will reflect a false reality: That testing is currently in progress, when in reality, it is not.

Building wait or “Ready” queues into the board design, as seen in this Kanban board example, can help teams get a more accurate picture of where work is in the process. By adding “In Process” and “Done” sublanes within the “Develop” step, the team can see which work items are actively being worked on, which have been “developed” but have not yet begun testing, and which work items are actually in the testing phase.

Instead of pushing the work item into the “Test” lane, the developer can place it in a “Ready” queue, allowing the tester to pull it into the appropriate lane when they’re actually ready to begin testing.

Implementing WIP limits

Work-in-process, or WIP, limits are another key Kanban concept that can help all teams, including development teams, actively manage the flow of work through their system. In this Kanban board example, the team is using WIP limits to limit the number of work items that can exist in any given step at any given time.

This development team is using WIP limits to specifically limit the number of tasks in certain lanes. You’ll notice that not all lanes have WIP limits built in (visualized with numbers located in the top right of the lane title). These are likely the steps that the team has identified as being most likely to overwhelm the system, either because the team’s capacity to complete those steps is limited, or because the tasks themselves are inherently complex (or a combination of these two factors).

Visualizing WIP limits in a passive way can be helpful, but only if those limits are respected. Using an online Kanban board that enforces these limits, as seen in this Kanban board example, can make it more likely that your team will notice when WIP limits are being met or exceeded.

The nature of the work done by IT operations teams often results in conflicting priorities: Project-driven work and routine maintenance get reprioritized when more urgent break-fix work is required.

Using Kanban boards to visualize their work, teams can communicate priority conflicts, zero in on how to solve them, and help get work flowing again. These Kanban board examples for IT Operations teams illustrate how teams can manage different types of demand, visualize shifting priorities, and reflect team member specialties while keeping everyone aligned.

Managing different types of demand

Horizontal swimlanes show different types of demand more clearly, bringing greater transparency to what’s being worked on and illuminating bottlenecks that can slow the team. Segmenting by demand type can also give better insight when reviewing board reports; e.g., if your cumulative flow diagram shows longer cycle times for unplanned work than production problems, you know where to focus improvements.

Visualizing changing priorities

Any team can use a Kanban board to stay on top of shifting work priorities. In the IT Operations example above, the “On Hold” lane exists below the “In Work” lane to explicitly disclose when a work item is stuck or cannot progress further. Visual icons are also being used to indicate critical work, work that has displaced other work, and blocked work.

Notice in the far left lane, this team is using a “Legend” lane to explain how to use icons and policies so the team can stay aligned on what each of these visual cues represent.

Some teams find it more helpful to divide in-progress work by subteam / specialties than by types of demand. This Kanban board example for IT Operations illustrates how horizontal swimlanes can be used to track and manage the work of subteams while keeping the team aligned.

You don’t have to practice Kanban to use a Kanban board. Many teams use Kanban boards to visualize the work flowing through their Scrum, Scrumban, waterfall, or other hybrid process.

Managing scrum sprint tracking on a kanban board

Scrum teams can visualize and track the work items prioritized for the current sprint using the “Development In Process” section of the board. The team pulls stories from the “Current Sprint Backlog” and manages task details in the corresponding horizontal feature lane to quickly see sprint status.

The Scaled Agile Framework (SAFe®) provides a recipe for applying Lean-Agile practices at enterprise scale. Kanban boards can be used to manage SAFe adoption at the portfolio, program, and team levels.

This board layout makes it easy to distinguish between Business and Architectural epics and track your initiatives through to implementation. Using a Kanban board at the portfolio level helps you visualize your organization’s cross-program initiatives and facilitates strategic decision making.

This board example is designed to coordinate the efforts of multiple teams. This allows you to create a single Program Backlog for each Agile Release Train, breaking down epics into features for prioritized delivery in Program Increments.

ART-level SAFe kanban board

This Kanban board example shows how you can represent different workflows on the same board, giving teams the flexibility to use – and transition to – any methodology they like. Teams use the Agile Release Train board to break down features into user stories and manage them through to implementation.

Sometimes it’s easier to create or improve your own board layout after you’ve seen examples of Kanban boards used by teams like your own. Exploring other board layouts can inspire how you visualize your work and how you work together within your team. When you’re borrowing board layout ideas, remember to respect your own team’s way of working as much as possible.

In this article, we’ve shared examples of Kanban boards from development teams, IT Operations teams, and teams practicing Scrum and SAFe. Although all of these examples are related to software product development or maintenance, the Kanban concepts we’ve shared can be applied to virtually any type of team.

Kanban boards can also be used by teams that aren’t following the Kanban method, but need a way to visualize their workflows, such as teams practicing Scrum, waterfall, or hybrid methods, as well as SAFe.

If your team is completely new to Kanban, it can be helpful to start with the basics before diving into the more mature Kanban concepts we’ve shared in this article. Like with any business methodology, it’s always important to align around the why before trying to implement the what or how.

First, make sure your team has a solid understanding of Kanban principles: Respect for people and continuous improvement. Then, help them understand the elements of a Kanban board and how they will enable them to improve task management and their work lives. For example, Work in Progress (WIP) limits will keep them from being overcommitted, and help prevent them from feeling overwhelmed.

Other steps to take in preparing the team to use Kanban boards include:

• Identify the start and end points for your team to mark the beginning and end of its workflow
• Review current processes, roles, and responsibilities
• Ensure the team understands and is committed to continuous improvement
• Encourage leadership qualities at every organizational level

Some cultural changes may need to take place as the team moved toward Kanban board adoption. For example, team members might feel nervous when they hear that Kanban boards are effective at pinpointing weaknesses in the team’s process. Assuring them that continuous improvement is the goal can ease their discomfort.

Once a foundation is established with the team, the Kanban board examples provided above will be helpful in generating discussion. Over time, the entire team will be instrumental in critiquing and refining the process.