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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
A physical or virtual board that is organized into columns — each column represents a status. Common statuses include: Up Next, In Progress, and Done.
Indicates a problem with a work item that prohibits it from moving forward.
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.
The time it takes for a card to move from prioritization to completion.
The time it takes for a card to be prioritized from when it was added to the backlog.
Hybrid methodology originally meant to facilitate teams moving from scrum to kanban.
Horizontal lines that split status columns into sections. Swimlanes can be used to represent teammates or organize tasks by type/priority.
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.
There are no defined roles but some teams have service delivery and service request managers.
Product owner, scrum master, and development team
Defined intervals called sprints (e.g. two weeks)
At the end of each sprint, as approved by the product owner
Change can happen at any time.
Changes should not be made to the sprint forecast during the sprint.
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).
Lead time and cycle time
Velocity and planned capacity
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:
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.
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.
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.
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.
See how you can customize kanban workflows for your team and build your way — try Aha! Develop for free for 30 days.
- What is agile software development?
- What is an agile roadmap?
- What are the most common agile development methodologies?
- Agile vs. lean
- Agile vs. waterfall
- What is the Scaled Agile Framework (SAFe®)?
- What are best practices of agile development teams?
- What is unit testing?
- What is DevOps?
- What are some DevOps best practices?
- DevOps and "continuous everything"
- What is an agile retrospective?
- Introduction to agile metrics
- What is a burndown chart?
- What is agile transformation?
- What is issue tracking?
- What is the role of a software engineer?
- Agile glossary