hamburger__close
Kanban is a visual workflow management method that uses boards, cards, and work-in-progress limits to control the flow of tasks through a system, pulling work forward only when capacity allows. Originating in Toyota’s manufacturing plants in the 1950s, it has since become a recognised project management competency practised across industries worldwide. Understanding Kanban is no longer optional for project professionals who want to lead adaptive, high-performing teams in any sector. This guide explains what Kanban is, how it works, where it came from, and why it matters for your career as a credentialled project manager.
Kanban is a visual workflow management method that limits the amount of work in progress, pulls tasks forward based on team capacity, and creates a continuous, transparent flow of deliverables. The word itself is Japanese, meaning ‘signboard’ or ‘visual card’, and that simple idea sits at the heart of everything the method does: making work visible so that problems surface quickly and teams can respond with clarity rather than guesswork.
In plain terms, Kanban is a way of managing work by showing every task on a shared board, agreeing how much work can be active at any one time, and ensuring new tasks only begin when existing ones have progressed. It is not a prescriptive process with fixed roles or ceremonies. It is a set of principles and rules applied to whatever workflow a team already uses, gradually improving it through measurement and reflection. That flexibility is exactly why the Institute of Project Management recognises Kanban as a valued competency within a broader project management toolkit, rather than a niche technique belonging only to software developers.
To understand Kanban fully, it helps to know where it came from. In the late 1940s and early 1950s, Toyota engineer Taiichi Ohno was studying the inefficiencies of traditional mass production and looking for a smarter way to manage the flow of materials through a factory. He drew inspiration from an unlikely source: the supermarket. In a supermarket, shelves are restocked only when items are taken by customers. Supply responds to actual demand rather than to forecasts or production targets. Ohno saw immediately that the same logic could transform manufacturing.
He introduced physical cards, called kanban cards, to signal when a workstation needed more materials from the previous stage of production. This created what Toyota called a ‘pull system’, in which work moved forward based on genuine need rather than being pushed forward on schedule regardless of whether the next stage was ready. The result was less waste, fewer bottlenecks, and a factory floor that could respond dynamically to change. By the 1990s and early 2000s, thinkers in the software and project management world began adapting these same principles. David Anderson is widely credited with formalising the Kanban Method as it is understood in knowledge work today, publishing his influential work in 2010 and establishing a framework that project managers, not just factory managers or engineers, could adopt and build upon.
The Kanban Method, as defined for knowledge work, rests on four foundational principles that distinguish it from more prescriptive frameworks. These principles explain why Kanban is particularly well suited to teams and organisations that need to improve without tearing up their existing processes and starting again. Understanding these principles is essential for any project management professional who wishes to apply or advocate for Kanban within their organisation.
The first principle is to start with what you do now. Kanban does not ask a team to discard its current roles, tools, or processes. It asks them to visualise and understand what they already do before attempting to change anything. This respect for existing practice reduces resistance and makes adoption far more achievable in real organisations.
The second principle is to agree to pursue incremental, evolutionary change. Rather than transforming a team or organisation overnight, Kanban encourages small, evidence-based improvements made steadily over time. This reduces risk and aligns naturally with the continuous improvement philosophy central to professional project management standards.
The third principle is to initially respect current roles, responsibilities, and job titles. Kanban recognises that organisational change is difficult and that abrupt role changes create anxiety. By preserving existing structures at the outset, teams can focus on improving workflow rather than navigating political or structural disruption.
The fourth principle is to encourage acts of leadership at all levels. Kanban does not reserve decision-making for senior managers. It expects everyone, from team members to executives, to identify problems, suggest improvements, and take responsibility for the quality of the flow. This democratised leadership approach aligns closely with modern IPMA-aligned competency frameworks that value adaptive, collaborative project leadership.
If you are ready to formalise your knowledge of adaptive project management methodologies, including Kanban, within a structured and internationally recognised learning pathway, IPM’s Certified Agile Project Management course provides the depth and credentialling context that career-focused professionals need. It situates Kanban alongside Scrum, Lean, and hybrid approaches within a competency framework aligned with global project management standards.
Alongside its four core principles, Kanban is governed by six operational rules that define how the system functions day to day. These rules are not optional guidelines. They are the mechanisms through which the principles become practice, and understanding them is fundamental for any project manager seeking to implement or assess Kanban in a professional context.
The first rule is to visualise the workflow. Every step in the process must be represented on the Kanban board so that all stakeholders can see where work stands at any given moment. This transparency is the starting point for every other improvement.
The second rule is to limit work in progress. Each stage of the board carries a cap, known as a WIP limit, that restricts how many tasks can occupy that column simultaneously. When a column is full, no new work enters until something moves forward. This single rule is arguably the most powerful in the entire method, as it forces teams to finish work rather than simply starting more.
The third rule is to manage flow. Teams measure how work moves through the system, identifying where tasks stall or accumulate, and then addressing those blockages systematically.
The fourth rule is to make process policies explicit. The rules governing how work is handled at each stage must be clearly defined and visible to everyone. Ambiguity about when a task moves from one column to the next is a common source of delay and inconsistency.
The fifth rule is to implement feedback loops. Regular review meetings, such as daily stand-ups and service delivery reviews, create structured opportunities for the team to reflect on performance and adapt accordingly.
The sixth rule is to improve collaboratively and evolve experimentally. Changes to the system should be agreed upon together and tested in a disciplined way, using data from the board to evaluate whether an experiment has worked before adopting it permanently. This rule is what gives Kanban its character as a learning system rather than a fixed methodology.
One of the most common points of confusion for professionals new to adaptive project management is the relationship between Kanban and Agile. The short answer is that Kanban is not a competing alternative to Agile. It is one approach that exists within the broader Agile family of thinking, sharing its values while differing significantly in structure and implementation. Agile is a philosophy and set of values, articulated most famously in the 2001 Agile Manifesto. Kanban is a method for managing work that aligns with those values without prescribing the specific roles, sprints, or ceremonies associated with frameworks such as Scrum.
Where Scrum organises work into fixed-length iterations called sprints and defines specific roles such as Scrum Master and Product Owner, Kanban is continuous and role-neutral. Work flows through the system at whatever pace the team’s capacity allows, and there are no mandatory planning or review cycles baked into the method itself, though teams are encouraged to establish their own feedback loops. This makes Kanban particularly suitable for teams whose work is unpredictable in volume or type, such as operations teams, support functions, maintenance projects, or multi-stakeholder programmes where priorities shift frequently. The detailed comparison of Kanban vs Scrum available from IPM explores this distinction further, but the essential point for project managers is this: both approaches serve different contexts, and a well-rounded professional understands when to apply each one. You can explore further perspectives on the broader Agile and Lean connection in IPM’s dedicated piece on Lean Kanban.
The Kanban board is the central artefact of the method, and understanding its structure helps demystify how the system operates in practice. At its most basic, a Kanban board is divided into columns representing stages of a workflow, with individual cards representing discrete units of work. The most common starting configuration is three columns: To Do, In Progress, and Done. As teams mature, they typically add columns that reflect the real stages of their specific workflow, such as Analysis, Development, Review, Testing, and Deployment in a technology context, or Scoping, Drafting, Approval, and Published in a content production setting.
Each card on the board represents a single task or work item and typically carries key information: a brief description of the task, who is responsible, when it was started, and any relevant deadline or priority flag. As a task progresses, its card moves from left to right across the board, making the state of every piece of work instantly visible to anyone who looks.
WIP limits are the rules that govern how many cards can occupy each column at any one time. If the In Progress column has a WIP limit of three and all three slots are occupied, no new card can enter that column until one of the existing cards moves to the next stage. This creates productive pressure. Rather than picking up fresh work the moment a blocker appears, team members are prompted to help unblock existing work first, which improves overall flow and reduces the costly context-switching that slows teams down. Measuring flow metrics such as cycle time (how long a task takes from start to finish) and throughput (how many tasks are completed per week) gives project managers the evidence they need to make intelligent, data-driven improvements to the system over time.
One of Kanban’s most compelling qualities as a project management competency is its adaptability. Because the method starts with an existing workflow rather than imposing a new one, it can be applied in virtually any environment where work needs to be managed, tracked, and improved. Understanding the breadth of its application is important for project managers who will work across sectors throughout a career.
In manufacturing, Kanban retains its original purpose of controlling the supply and production of physical goods, minimising overproduction and reducing inventory waste in line with Lean principles. In software development, it has become a cornerstone of Agile delivery, helping development and operations teams manage feature requests, bug fixes, and releases in a continuous flow without the constraints of fixed iterations. The IPM blog covers a wide range of such applications for project management professionals at every stage of their career.
Beyond technology, Kanban is increasingly used in marketing and communications teams managing campaign pipelines, in human resources managing recruitment and onboarding workflows, in financial services managing compliance and audit processes, and in healthcare settings managing patient care pathways. In each of these contexts, the core mechanism is identical: make work visible, limit what is active, manage flow, and improve continuously. What changes is the language and the shape of the board, not the underlying discipline. For project managers, this universality is a significant professional asset. A practitioner who understands Kanban can apply it meaningfully across multiple sectors and organisational types, making it a genuinely transferable competency rather than a tool tied to one industry or function.
This is where IPM’s perspective diverges from much of what you will find written about Kanban elsewhere. Most discussions of the method treat it as a productivity technique, a workflow tool, or an Agile framework for software teams. These descriptions are not wrong, but they are incomplete. For professional project managers who operate within accredited competency frameworks aligned with global standards such as those promoted by the IPMA, Kanban represents something more significant: a recognised approach to adaptive delivery that belongs within a broader portfolio of project management knowledge and skill.
IPMA-aligned competency models describe project management in terms of people competences, practice competences, and perspective competences. Kanban, understood properly, touches all three. It requires practitioners to lead collaboratively and foster a culture of continuous improvement (people). It provides concrete practices for planning, monitoring, and controlling work in adaptive environments (practice). And it reflects a systems-thinking perspective on how organisations deliver value through managed, visible, and measurable workflows (perspective). This means that for a project manager seeking to broaden their professional credentials, understanding Kanban is not an optional extra. It is a component of being a well-rounded, adaptable practitioner capable of selecting and applying the right approach for the right context.
Certified Agile project managers are increasingly expected to demonstrate fluency across multiple adaptive frameworks, including Kanban, Scrum, and hybrid approaches that combine elements of both. The ability to explain why Kanban is appropriate for a particular team or project, to implement it with rigour, and to measure its effectiveness using flow data is the kind of applied competency that distinguishes a certified professional from someone who has simply attended a workshop. If you are studying for project management certification or building a case for professional development investment, Kanban belongs on your curriculum alongside other established methodologies. It is not a soft skill or a creative technique. It is a discipline with defined principles, measurable outcomes, and a growing body of professional practice standards behind it.
For those looking to formalise their understanding of adaptive approaches within a structured learning pathway, IPM’s Certified Agile Project Management course covers Kanban alongside other adaptive methodologies, situating each within the competency frameworks that modern employers and certification bodies recognise. Professionals who already hold or are pursuing Scrum credentials may also wish to explore how Kanban complements that knowledge through IPM’s Professional Scrum Master and IPM Scrum Master programmes, which contextualise these related frameworks within the same adaptive delivery mindset.
Given how widely the word ‘Kanban’ is used across different industries and disciplines, it is unsurprising that several misconceptions have grown up around it. Addressing these directly helps project management professionals engage with the method on accurate terms, which matters particularly when making the case for its adoption within an organisation or when preparing for professional assessment.
The most common misconception is that Kanban is simply a board with sticky notes. The board is a tool, not the method itself. Kanban is the system of principles, rules, and feedback mechanisms that gives the board its meaning. A board without WIP limits, explicit policies, and flow measurement is not Kanban. It is a to-do list on a wall. A second misconception is that Kanban is only for technology teams. As explored earlier, the method applies to any workflow, and its most powerful early applications were in physical manufacturing, not software. A third misconception is that Kanban and Scrum are interchangeable. They are related but distinct. Scrum prescribes a structure, including roles, ceremonies, and time-boxed sprints. Kanban prescribes a set of principles and rules that can be applied to any existing structure. Choosing between them, or combining elements of both in a hybrid approach, is a professional judgement that depends on the nature of the work, the team’s maturity, and the organisation’s context. Understanding this distinction is itself a mark of professional competency.
For project managers who are new to Kanban, the good news is that getting started does not require a wholesale change to the way a team operates. Recall the first principle: start with what you do now. The practical entry point is to map the team’s current workflow honestly, listing every stage that work passes through from initial request to final delivery. Then create a board that reflects those stages as columns, add cards representing current work items, and agree on a WIP limit for at least one column, typically the most congested one.
Hold a brief daily meeting, no longer than fifteen minutes, where the team reviews the board from right to left, meaning from tasks nearest to completion backwards. This counterintuitive direction focuses attention on finishing work rather than starting new tasks, reinforcing the pull system at the heart of the method. After two to three weeks, measure how long tasks are taking to move through the board and where they tend to stop. Use those observations as the basis for a team conversation about one small change to try. This iterative, evidence-based approach to improvement is not just good Kanban practice. It is recognisable as good project management practice in any context, which is precisely why Kanban translates so naturally into the broader discipline.
Project managers who commit to understanding Kanban properly, including its historical roots, its governing principles, and its place within accredited methodology frameworks, will find it a genuinely versatile and career-enhancing competency. The Institute of Project Management has supported professionals in building exactly this kind of rounded, methodology-literate expertise for over 35 years, and Kanban is an increasingly important part of that professional picture.
Kanban is a method for managing work by making every task visible on a shared board, limiting how many tasks can be active at once, and ensuring new work begins only when there is capacity for it. It uses a pull-based flow, meaning work is pulled forward by available capacity rather than pushed forward by a schedule. It applies to any workflow in any industry and improves performance through transparency and continuous incremental change.
The four core principles of Kanban are: start with what you do now; agree to pursue incremental, evolutionary change; initially respect current roles, responsibilities, and job titles; and encourage acts of leadership at all levels. These principles mean that Kanban improves existing systems gradually rather than demanding radical transformation, making it one of the most practically adoptable methods in professional project management.
Agile is a philosophy and set of values for delivering work adaptively and collaboratively. Kanban is one method that aligns with Agile values. Kanban differs from Agile frameworks like Scrum because it does not prescribe fixed roles, sprints, or ceremonies. Instead it applies principles and rules to whatever workflow already exists. A project manager who understands both can choose the right approach based on context, team maturity, and the nature of the work.
The six rules of Kanban are: visualise the workflow; limit work in progress; manage flow; make process policies explicit; implement feedback loops; and improve collaboratively and evolve experimentally. Together these rules turn the board from a passive display into an active management system. They give project managers a clear operational framework for implementing Kanban with the rigour expected of a professional methodology rather than an informal practice.
In a business context, Kanban is a method for managing any kind of work, from product development and service delivery to operations and administration, by making work visible, controlling the volume of active tasks, and improving the speed and quality of delivery over time. It is used by teams across manufacturing, technology, marketing, finance, healthcare, and professional services, making it one of the most broadly applicable workflow management methods available to project managers.
In manufacturing, Kanban was originally developed by Toyota engineer Taiichi Ohno as a system of physical cards that signalled when workstations needed more materials from upstream in the production process. This created a pull system in which supply responded to actual demand, reducing overproduction, waste, and inventory costs. It remains widely used in manufacturing and supply chain management today and forms part of the Lean production philosophy that has influenced modern project management practice globally.
Kanban is far more than a board covered in sticky notes. It is a disciplined, principle-driven method with deep roots in industrial engineering and a well-established place within modern project management practice. For project professionals who want to lead adaptive teams, hold their own in methodology conversations, and build a credentialled career that spans sectors and contexts, understanding Kanban is an essential step. Explore IPM’s full range of learning resources at the IPM blog to continue building your professional expertise.
| Key Aspect | What to Know | Why It Matters |
|---|---|---|
| Origin | Developed by Taiichi Ohno at Toyota in the 1950s as a manufacturing pull system | Proven foundations in operational efficiency with decades of real-world validation |
| Core mechanism | Visual boards, WIP limits, and pull-based flow of work items | Immediate visibility of work status and bottlenecks for faster decision-making |
| Guiding principles | Four principles including starting with existing processes and evolving incrementally | Low adoption risk and high organisational acceptance compared to prescriptive frameworks |
| Operational rules | Six rules covering visualisation, flow management, explicit policies, and feedback loops | A clear professional framework for implementing Kanban with measurable rigour |
| Relationship to Agile | An Agile-aligned method that differs from Scrum by being continuous and role-neutral | Applicable to unpredictable, variable workloads where fixed sprints are impractical |
| Industry applicability | Used across manufacturing, technology, marketing, healthcare, finance, and more | A transferable competency that adds value across sectors throughout a project management career |
| Career relevance | Recognised within IPMA-aligned competency frameworks as an adaptive delivery method | Strengthens professional credentials and broadens methodology fluency for certified PMs |
