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.

Kanban is not a methodology. Rather, it is a system that agile teams use to continuously deliver high-value features. Many product and software development teams rely on kanban boards as a simple, effective way to visualize work. This is why tools like Aha! Create, Roadmaps, and Develop come with built-in kanban functionality — including kanban-style workflow boards for product teams and developers.

The free kanban board template in Aha! Create gives you a whiteboard-style view ideal for getting started quickly. The kanban boards in Aha! Roadmaps and Aha! Develop are built for product and engineering teams respectively — useful if you want to plan, assign, and track features through to delivery.

Try the kanban board template in Aha! Create — free to use.

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.

Manage work on a kanban board in Aha! Develop — sign up for a free trial.

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

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.

Backlog

Consolidated list of work items (e.g. user stories, bug fixes) that need to be completed but have not yet been prioritized. Typically the first column on your board is the backlog.

Boards

A physical or virtual board that is organized into columns — each column represents a status. Common statuses include: Up Next, In Progress, and Done.

Blocked

Indicates a problem with a work item that prohibits it from moving forward.

Cards

An individual work item, such as a user story or feature.

Cumulative flow diagram

A visual chart that shows cycle time, work in progress, and throughput during a given time period in colored bands.

Cycle time

The time it takes for a card to move from prioritization to completion.

Lead time

The time it takes for a card to be prioritized from when it was added to the backlog.

Scrumban

Hybrid methodology originally meant to facilitate teams moving from scrum to kanban.

Swimlanes

Horizontal lines that split status columns into sections. Swimlanes can be used to represent teammates or organize tasks by type/priority.

Throughput

The number of cards that move through statuses during a given time period.

Work-in-progress (WIP) limit

How many cards can be worked on at any time, in any status/lane.

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.


Kanban

Scrum

Roles

There are no defined roles but some teams have service delivery and service request managers.

Product owner, scrum master, and development team

Release cadence

Continuous

Defined intervals called sprints (e.g. two weeks)

Delivery

Continuous

At the end of each sprint, as approved by the product owner

Change

Change can happen at any time.

Changes should not be made to the sprint forecast during the sprint.

Meetings

There are no defined meetings but meetings are broken out by team-level (e.g. daily standups) and service-level (e.g. delivery and risk review).

There are four mandatory meetings: sprint planning, daily scrum, sprint review, and sprint retrospective.

Performance metrics

Lead time and cycle time

Velocity and planned capacity

Related guides:

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.

Implement kanban on your agile team — sign up for a free trial of Aha! Develop.

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:

Portfolio

Kanban is used at the portfolio level to manage the flow of epics. These are large initiatives across the organization that span teams and multiple releases. Portfolio kanban encourages transparency in decision-making processes and provides work-in-process limits across teams.

Solution

Kanban is used at the solution level to manage a team's capabilities. For example, establishing a continuous delivery pipeline could be its own unique kanban.

Program

Kanban is used at the program level to manage features for an Agile Release Train (ART) — which includes all of the work needed to build, test, deploy, and release new software or a customer experience.

Team

Kanban is used at the team level to manage an individual team's workflows. For example, product managers apply kanban when working from discrete planning boards. Agile engineering teams apply kanban when managing user stories and the engineering backlog. Some organizations choose to visualize all teams on one board with a lane per team to provide better transparency and alignment.

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.

Kanban and Aha! software

Teams that use Aha! software can practice kanban in a variety of ways. Here is a brief overview of how to use kanban boards in Aha! Create, Roadmaps, and Develop:

  • Aha! Create: Build a lightweight kanban board using columns and sticky notes. This kind of view is particularly helpful for early visualization, planning, and discussion of upcoming work.

  • Aha! Roadmaps: Focus on strategic product planning. Show epics, features, or requirements on your kanban board, then group cards into swimlanes to visualize the work items the team is responsible for.

  • Aha! Develop: See day-to-day developer workflows on a customizable kanban board. Include details such as estimated effort, individual or team ownership, and the status of each work item.

Customization is key. Whether you are a member of a product or development team, choose a tool that allows you to easily design your kanban board and workflows to meet your specific needs. This way you can boost your team's productivity and be happy as you deliver greater value, faster.

Product development software that your entire team will love. Try Aha! free for 30 days.