What is kanban?

Kanban is a workflow management system that helps agile software development teams define and manage their work and continuously improve their performance. The term means "billboard/placard” in Japanese — which hints at the trademark kanban workflow organization system based on cards. Each card on a kanban board represents a work item and is moved across the board into vertical columns that represent status. A team's kanban board is always in motion — new features are pulled from the backlog and added to in-progress work as team capacity allows.

Practical example of a kanban board created in Aha! Develop

Kanban is not a methodology. Rather, it is a system that agile teams use to continuously deliver high-value features. It continues to gain popularity in software development because it is a simple, effective way to visualize work.

Kanban stands out because it is a pull system. Practically speaking, this means two things. First, work is only pulled when there is an actual demand for it (versus when it is anticipated). And secondly, team members only pull work when they have the capacity to complete the task.

Software development is not exactly a predictable endeavor. While work is often pushed onto development teams based on estimates of team capacity, those estimates can be faulty. Kanban establishes work in progress (WIP) limits and measures throughput to help teams prioritize requests and maintain manageable workloads.

Teams that practice kanban are typically self-directing — they determine when and how work is completed. Resources are only pulled in as they are needed or requested and teammates claim work based on actual bandwidth. This is a huge contrast to being assigned future work by someone else using capacity estimates.

This guide provides an overview of the origins of kanban, the principles of the method, and the processes for implementation:

• Origins of kanban

• Principles and practices of kanban

• Kanban glossary

• Kanban metrics

• Kanban vs. scrum

• Benefits of kanban

• Implementing a kanban system

• Scaling kanban

The origins of kanban

Taiichi Ohno introduced kanban at Toyota in the late 1940s. He was an industrial engineer and eventual executive at the company. Today he is considered the “father” of the Toyota Production System, which inspired lean manufacturing in the United States.

At the time, Toyota was struggling to compete with the American car market. So Toyota looked at how other supply chains handled fulfillment by matching inventory levels with consumption patterns. Specifically, they studied supermarkets. Stores stocked products based on what they could sell in a specific time. Customers bought what they needed since they knew they could buy more later. This research led Toyota to see consumer demand as part of the manufacturing process — a required input precedent to production.

Most car manufacturers still followed Henry Ford’s method, producing a great quantity of parts (doors, engines, etc.) that were piled beside the assembly line to be used as needed. But this approach required huge amounts of upfront capital, which was challenging in post-World War II Japan. Ohno aimed to eliminate overproduction by introducing new inventory only when absolutely necessary. Factories were reorganized so that parts production and assembly happened at the same rate, with assembly workers taking parts only as needed. They called it the “just in time” (JiT) method — but more on that later.

Remember that supermarket research? Ohno realized that there needed to be some exchange that triggered restocking the shelves. So he introduced paper cards called kanban. Once a material was used, a kanban card would be sent back to parts production indicating to the team exactly what was used and how many more were needed to restock.

Over time the kanban method evolved to support many different supply chains — basically anything that required visualization of a large volume of in-progress work. But the next evolution of kanban occurred in the early 2000s when the method was adopted as a project management tool by IT and software development teams.

Many assumed lean manufacturing principles would not extend to knowledge work. But a 2004 case study of IT teams at Microsoft proved the efficacy of these concepts in managing change requests and backlogs. One of the authors of that case study, former Microsoft engineer David J. Anderson, was credited as among the first to apply kanban to software development. He went on to write many books about agile and lean methodologies. (And he even opened a kanban “university” as well as his own eponymous school of management.)

What are the principles and practices of kanban?

Kanban is a system, not a philosophy of work. Unlike other agile frameworks, there is not a list of rules, roles, and ceremonies that must be followed to “do kanban right.” But there are some general principles and practices, which include these six:

1. Visualize work. Development work is often “invisible” until it is completed. So it is useful to have a high-level view of work items to understand status and progress. This is where kanban boards come in.

2. Limit WIP. You can complete projects faster if you prioritize what is most important, limit how much work each person has, and focus on completion before moving onto the next item.

3. Manage flow. Managing flow is not about managing the people doing the work — it is about managing the work processes themselves. This requires a deep understanding of how these processes function, the causes at the root of roadblocks, and where processes can be improved to finish work faster.

4. Make process policies explicit. The first step to process improvement is understanding current processes. Your aim should be creating clear documentation that everyone can easily access. Transparent documentation can inspire self-sufficiency, increase shared knowledge, and improve onboarding.

5. Implement feedback loops. Feedback loops (also called cadences) help the team communicate with stakeholders and respond to changes in workflows and priorities. Daily team kanban meetings are one example of a feedback loop in practice. Similar to daily standups in scrum, these meetings are opportunities to discuss capacity, report on progress, and raise any concerns.

6. Improve collaboratively. Continuous, sustainable improvement requires team collaboration — you need to achieve consensus on what is changing and why. Ask "what if?" and test hypotheses, then track the impact of changes on team performance. For example, you can use a throughput report to track how many kanban cards the team completes in a given time period. This data will help you better understand current capacity and whether to adjust what you commit to.

Bonus principle: Just in time (JiT). JiT puts an emphasis on delivering the simplest solution to a known issue in small releases to avoid waste — versus anticipating future unknown needs. It might not be a principle of kanban per se, but it is definitely part of the conversation.

The above practices should form the foundation of your kanban approach. Think of them as constant areas of improvement, rather than as goals to achieve and then check off your list.

Kanban definitions

Although kanban does not have the plethora of terminology associated with many agile workflows, there are a few that those new to the method might not be familiar with.

Common kanban metrics

How do you know if your team is successfully meeting goals? You benchmark and measure progress. Quantifiable data can give you meaningful insights into what is working and where processes are breaking down. And tracked over time, this data reflects real and ongoing improvement.

Here are some common kanban metrics you can use to evaluate your team's productivity and performance:

• Cycle time: The amount of time spent actively working on a task (or card).

• Lead time: The total amount of time a task spends in your system from initial recording through delivery.

• Queues: Stages in your workflow when cards are not active, but in a holding pattern. Ex: "Waiting for review" is a common queue.

• Throughput: The number of tasks or cards completed in a given time period.

• When will it be done: A forecast of when work will be completed based on combining historical data on lead times, cycle times, and throughput.

• Work in progress: Items that are in production but not yet completed.

  

An example of a throughput report created in Aha! Develop showing average points completed over time.

Kanban vs. scrum

It is worth taking a moment to compare kanban to one of the other most popular agile frameworks: scrum. Where kanban pulls, scrum pushes. Kanban is flexible, while scrum has a defined framework. Kanban limits WIP to balance work against actual capacity, scrum relies on estimation in story points. The table below gives you a high-level comparison of the two.

Related guides:

• What is scrum?

• How to implement scrum

What are the benefits of kanban?

Organizations often see radical increases in productivity as a result of adopting the kanban method. Kanban increases transparency and communication since work and status is visualized in one place. With a glance, you can evaluate who has the most work and who has the least.

But in the minimalist spirit of the method, here is a simple list of benefits:

• Flexibility — no defined framework makes it adaptable to different organizations.

• Delivery — continuous delivery means faster value creation with more opportunities to incorporate feedback into future iterations.

• Productivity — priorities are constantly reassessed based on the most recent information.

• Decreased waste — less questioning about what to work on next, less administrative overhead.

• Morale — teammates have more room to focus on work and process improvement is collaborative.

How to implement a kanban system

A kanban system is a defined workflow management method. It is about defining, managing, and improving the delivery of services. You are able to visualize your work, reduce waste, and better respond to change.

The practices referenced earlier provide a blueprint for effectively implementing kanban on your own team. Here is a brief summary of the steps to take:

1. Visualize work

Map out the processes that you currently use to deliver new functionality to the columns that will be on your board. You will also want to decide how you will actually manage your board. Are you happy with the tactile nature of a physical sticky note board? Or do you want a more dynamic virtual kanban board?

2. Set your WIP limits

Decide on a limit for the number of cards that can exist at any time in any column.

3. Make policies explicit

Capture exactly how the backlog will be managed and define how you will handle defects and bug fixes.

4. Measure and manage flow

Delivering continuously means you need to insert criteria for evaluating and understanding your performance. Most teams use cycle time and throughput to do this.

5. Gather feedback and optimize

Every teammate should feel empowered to give feedback on how processes can be improved at every phase of work. Approach each optimization like a scientific experiment — formulate a hypothesis, then monitor the outcome of any changes you make.

How can kanban be used at scale?

Kanban at scale takes a multi-layered approach that treats the organization as a complete system. The Scaled Agile Framework® is a good example of this. In SAFe®, kanban is used to visualize workflows, establish work-in-process limits, measure throughput, and continuously improve processes — at every level of an organization. These levels include:

Ultimately, kanban is about more than just visualizing workflows. It pushes teams to set clear priorities and collaborate across the development lifecycle. But remember: kanban is limited to tactical decisions. For your work to truly deliver value and have long-lasting impact, it must be grounded in meaningful strategy. If you make sure to tie each card back to larger product goals and initiatives, kanban can be an effective way to improve the way you get work done.

See how you can customize kanban workflows for your team and build your way — try Aha! Develop for free for 30 days.