Inevitably, every process has a bottleneck: There is some step that has a lower capacity than the steps before or after it. This may be because there are fewer resources dedicated to performing this step, or because it requires more time to complete than the other steps in the process. Regardless, this bottleneck is the limiting factor for the capacity of your entire system.
Bottlenecks pose a serious threat to flow. They promote wasteful habits like context switching, which slows down the delivery of value. The first step in eliminating a bottleneck is to identify it, but that’s often easier said than done.
A well-designed Kanban board can provide valuable insights into your team’s flow — where you’re delivering fast, and where work is piling up. Introducing queue lanes can help you pinpoint the specific cause of your bottlenecks, so you can move closer towards continuous delivery.
Basic Board Layout
The board example below reflects a simple process for developing a software feature. It starts with a Backlog for all new work coming into the team’s work stream. Next are the four basic stages of that work: Analyze, Develop, Test, and Deploy. Each card on this board represents independent features that this team is delivering.
Kanban promotes a pull system, in which a team only pulls in new work when they have enough capacity. This ensures that the team and the individuals within it stay under their WIP limits (read our three-part series on WIP limits here).
In this example, there is twice as much work in the Develop lane than any other lane, which could suggest a bottleneck in development. It’s important to have a conversation about the work to understand the reality of the situation. Some of the work in the Develop lane may be currently in process, but some of it may also be waiting to be pulled into the next lane. This board design does not delineate between these two states.
Adding Queue Lanes
We can make this delineation by adding two sub-lanes for each of the work lanes: In Progress and Done. These new Done sub-lanes represent queued work that is waiting to be pulled into the next lanes when there is capacity. You may also hear queue lanes referred to as buffer or waiting lanes. By adding these queue lanes, we can see that development does not have an issue with too much work — rather, our testers are overwhelmed and do not have the capacity to pull new work.
By visualizing our queues, we can immediately recognize the true bottleneck — in the Test step, not the Develop step as we might have assumed.
Avoiding Duplicate Queues
Once you see the benefit of these Done queue lanes, you may be tempted to add more queue lanes, such as an upstream lane (Ready) to identify work the team has pulled but has not yet started. Resist that temptation. It creates duplicate queues that represent the same state as the Done step before them. Adding those lanes can make it more difficult to see bottlenecks, since the work that is stacking up could be spread across two lanes and may not be as obvious.
Duplicate queues can also encourage teams to push work from their Done lane into the downstream Ready lane, getting away from the pull system we are trying to promote with Kanban.
Final Thoughts
Queue lanes make it easy to see the difference between work that is truly in progress, versus work that is waiting to be pulled into the downstream lane. Once you have added queue lanes, you can implement WIP limits that accurately reflect the reality of your team’s capacity. This understanding of your team’s unique process will help you continue to maximize flow — and move closer towards continuous delivery.
![A Global Collaborative Work Management Blueprint [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
