Written by the AgileFever editorial team. Facts checked on November 6, 2026 against the official pages of the organizations named in this post. AgileFever sells training for some of the topics covered here, and we say so wherever it applies. Definitions come from the Kanban Guide and from Kanban University’s and David Anderson’s published material on the Kanban Method. The course price and batches are from AgileFever’s own product page.
Search for kanban principles and you will find pages that list four, five or six items, call them principles on one line and practices on the next, and never say which is which. That is why readers finish an article unable to answer a plain question: if I am setting up a board on Monday, what do I do, and what do I merely believe? This post separates the two, maps each principle to the practice that acts on it, and shows a support team turning each practice into a rule anyone can see on the board. If you want the older overviews, we have What is Kanban and what are its core principles and 4 key Kanban principles. This post is the one to read for the difference.
Kanban principles vs Kanban practices: the difference in one table
A principle tells you how to think when you must decide something. A practice tells you what to do and gives you something you can point at. You can test the line quickly: if a colleague can walk up to the board and check that it is happening, it is a practice. If it describes an attitude or a way of making choices, it is a principle.
| Kanban principles | Kanban practices | |
|---|---|---|
| Answers | Why, and how to decide | What to do, and what you can see |
| Form | A statement of belief or approach | A concrete activity or artifact: a board, a limit, a policy, a review |
| Can you audit it? | Not directly. You see it in the decisions people make | Yes. Look at the board and the calendar |
| Example | Start with what you do now | Visualize the workflow as it runs today |
| Fails when | People agree with it and change nothing | People copy it without knowing why, so the board looks right and behaves wrong |
Limit WIP is a practice, even though many pages list it as a principle. The same goes for visualizing the workflow. These are things you do. The principles sit behind them and explain what they are for.
The Kanban principles Kanban University lists
Kanban University’s introduction to the Kanban Method groups the principles into two sets of three. David Anderson, who developed the Kanban Method, published the same grouping in his own writing on the principles and practices. The first set covers how you change a team or organisation. The second covers how you run the service the team provides.
| Set | Principle (wording from Anderson’s article) | Plain meaning |
|---|---|---|
| Change management | Start with what you do now | Map and run the process people follow today, not an imagined target process, and change it from there. |
| Change management | Agree to pursue improvement through evolutionary change | Make small, safe changes that the team has agreed to try, instead of a single large reorganisation. |
| Change management | Encourage acts of leadership at all levels | Anyone who sees a way to improve flow can act on it. Leadership is not a job title. |
| Service delivery | Understand and focus on customer needs and expectations | Define the work from the customer’s side: what they asked for and when they expect it. |
| Service delivery | Manage the work; let people self-organize around it | Managers watch work items and flow, and the people doing the work decide how to do it. |
| Service delivery | Regularly review the network of services and its policies in order to improve outcomes | Check how your service connects to others, and revisit your own policies on a schedule. |
Wording as published by David J. Anderson on djaa.com (page read November 6, 2026). Kanban University’s own introduction to the Kanban Method lists the same six in shorter form.
Some older lists, including ones you may have seen on other pages, show four foundational principles. They add a fourth: initially respect current roles, responsibilities and job titles. The idea is sound: do not reorganise people on day one. Current Kanban University material lists the three change management principles above.
The six general practices
In the same article Anderson lists six general practices. These are the activities that make the principles visible.
- Visualize (the work, the workflow, and the business risks)
- Limit WIP
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally (using models and the scientific method)
Two points trip people up. The count has changed over time, and Anderson’s article says the earlier set of five core properties in his book grew into the current principles and general practices. And pull is not on the list as its own item. Kanban University’s introduction lists WIP limits and pull among its specific practices, and the Kanban Guide describes pull as the result of controlling WIP. Our guide to the Kanban pull system goes through it.
Which practice enacts which principle
The pairing below is our own reading, not a table from Anderson or Kanban University. Several practices serve more than one principle, so the table shows the strongest link for each. Use it to ask a useful question about your board: which principle would this rule break if we removed it?
| Principle | Practice that enacts it | What you would see on the board |
|---|---|---|
| Start with what you do now | Visualize | Columns that match the steps people actually take, including the ugly ones such as waiting for approval |
| Pursue improvement through evolutionary change | Limit WIP | A limit set near current work in progress, then lowered one step at a time |
| Encourage acts of leadership at all levels | Improve collaboratively, evolve experimentally | Experiments proposed by anyone on the team, each with a stated hypothesis and a date to review |
| Understand and focus on customer needs and expectations | Make policies explicit | Written rules for what counts as done, how urgent requests are treated and the expected time to finish |
| Manage the work; let people self-organize around it | Manage flow | Review of aging items and blocked items, with no one assigning each person a task |
| Regularly review the network of services and its policies | Implement feedback loops | A calendar of reviews, such as a daily board review and a periodic service delivery review |
Choose the one your team argues about most, for example ‘start with what you do now’ when someone proposes redesigning the process first.
Use the table above. If you cannot name one, the principle is staying an opinion.
A column, a number, a policy line or a meeting slot. If it is not visible, it is not a practice yet.
Pick a flow measure such as cycle time or work item age. Record the value before you change anything.
Keep the rule, change it or drop it. This is the principle of evolutionary change applied to your own rules.
Worked example: a support team turns six practices into visible rules
Take a five-person IT support team. The ticket queue grows, customers chase for updates and urgent items interrupt everything. The team agrees to start with what it does now, so the first job is to write down what already happens. The numbers below are an invented example to show the shape of the rules. Your own limits will differ.
| Practice | Visible rule on the board | Principle it serves |
|---|---|---|
| Visualize | Columns: New, Triage, Investigating, Waiting on customer, Ready to reply, Resolved. Card colour shows ticket type: incident, request, question. | Start with what you do now |
| Limit WIP | Triage 2, Investigating 4, Waiting on customer 5, Ready to reply 2. Nobody pulls a new ticket into a full column. | Evolutionary change |
| Manage flow | Each morning the team reads the board from right to left and looks first at the oldest ticket. A ticket stuck in a column for 3 working days gets a blocker tag and a named owner for the next step. | Manage the work, not the workers |
| Make policies explicit | Resolved means the customer confirmed or did not reply for 3 working days. An incident marked urgent may break a limit once. Only one urgent ticket is allowed at a time. Service level expectation: 85% of tickets resolved in 5 working days or less. | Customer needs and expectations |
| Implement feedback loops | Daily 10-minute board review. Weekly look at tickets older than the expectation. Monthly review of the rules themselves. | Review the network of services and its policies |
| Improve collaboratively, evolve experimentally | Hypothesis: a separate Waiting on customer column shows that delay comes from replies, not from the team. Try it for 4 weeks, compare cycle time for the 4 weeks before. | Acts of leadership at all levels |
Invented example for illustration. The 85% and 5-day figures are placeholders; set yours from your own data. See our Kanban board examples for support and other team boards, and the Kanban board template for columns, limits and policies you can copy.
Every practice produced something you can check: the board, the limits, the calendar. The principles explain why the team did not start by redrawing the whole support process and why a manager reads the board instead of handing out tickets.
Why limiting WIP changes time to finish: Little’s Law
The practice that surprises new teams most is the WIP limit. Little’s Law, a result from queueing theory, explains it. For a stable system, the average time an item spends in the system equals the average number of items in progress divided by the average number finished per unit of time. In Kanban terms: average cycle time = average WIP ÷ average throughput. If throughput stays at 5 items a week, cutting WIP shortens the average time to finish. The bars show an invented team.
Little’s Law: average cycle time = average work in progress ÷ average throughput. Illustrative numbers, not data from any team.
The law assumes a stable system and gives averages, so it will not predict a single ticket. It also does not say the team will finish 5 items a week with less work in progress. Throughput can change, and that is why you record it before and after. The Kanban Guide defines throughput, cycle time and work in progress, and the Kanban metrics guide shows how to track them.
How the Kanban Guide’s three practices relate to the six
The Kanban Guide (version 2025.5, updated May 1, 2025) describes Kanban as a strategy for optimizing the flow of value through a process. It defines three practices that work together, and the set of them is a Kanban system. It also defines four flow metrics. It does not list the change management or service delivery principles, and it does not name the six general practices. Because the two documents use different words, a table helps. The right-hand column is our reading, not the Guide’s.
| Kanban Guide practice | What the Guide says it includes | Closest of Anderson’s six |
|---|---|---|
| Defining and visualizing the workflow | A definition of workflow: work items, start and finish points, states in between, how WIP will be controlled, explicit policies, and a service level expectation. It is shown on a board. | Visualize, Make policies explicit |
| Actively managing items in the workflow | Controlling WIP, preventing unnecessary aging of items, unblocking blocked work. Controlling WIP should create a pull system. | Limit WIP, Manage flow |
| Improving the workflow | Continuous improvement to balance effectiveness, efficiency and predictability. Changes can be made just-in-time. | Implement feedback loops, Improve collaboratively, evolve experimentally |
The four flow metrics in the Guide are work in progress (items started but not finished), throughput (items finished per unit of time), work item age (time since an item started) and cycle time (time between start and finish). In the older six-practice framing, you would call this measuring and managing flow. The six practices and the principles around them give a fuller picture of how to introduce change. The Guide is a short definition of what a Kanban system contains.
Common misreadings of Kanban principles and practices
Treating the two words as the same thing
Many pages call the six practices principles. In Anderson’s article they are practices, and the principles are a separate list. Use the right word and your team will argue about the right thing.
Believing there is one official count
There are 3 + 3 principles and 6 practices in one body of material, 3 practices in the Guide, and 4 foundational principles in older lists. None of them is a typo. Check the date and the author.
Reading ‘start with what you do now’ as ‘change nothing’
It means begin from the real process, not an idealised one. The next principle, evolutionary change, makes clear that the process still improves. Teams that hear ‘change nothing’ leave the board decorative.
Copying a board and calling it Kanban
A board without a WIP rule, explicit policies or a review is a task list. The Guide’s definition of workflow includes how WIP will be controlled and explicit policies for each state. Without them you have visualization only.
Where AgileFever fits
We sell Kanban University training, so weigh this section accordingly. Our Team Kanban Practitioner (TKP) course is a one-day live online class whose description covers Kanban principles, practices and designing your board. It is listed at $550 or ₹14,000 per seat as of November 6, 2026, with the regular price shown as $600 and ₹14,999. Rupee prices are before the 18% GST we add at checkout for buyers in India. Listed batches include Nov 7 to 8, Nov 20 and Nov 26 to 27, 2026, and Jan 8, 2027, as listed on November 6, 2026.
Additional discounts are available. Contact us to know more.
If you are not ready to book, use the board and the table in this post with your own team first. For teams planning a wider rollout, corporate Kanban training sets out which teams to train first, and STATIK is the method for introducing Kanban to a service. For more on the practices in a software setting, see Kanban practices for software development and Kanban practices for service delivery.
Questions people ask
What is the difference between Kanban principles and Kanban practices?
Kanban principles are the beliefs and approach that guide decisions, such as starting with what you do now. Kanban practices are the activities you can see, such as visualizing the workflow, limiting WIP and holding feedback reviews. Principles explain why. Practices are what the team does.
How many Kanban principles are there?
Kanban University’s introduction lists six: three change management principles and three service delivery principles. Older lists show four foundational principles. The Kanban Guide does not list principles, so the number depends on which document is quoted.
What are the six core practices of Kanban?
David Anderson lists them as visualize, limit WIP, manage flow, make policies explicit, implement feedback loops, and improve collaboratively and evolve experimentally. Some pages name five or use different words, so quote the source you rely on.
How many practices does the Kanban Guide define?
Three: defining and visualizing the workflow, actively managing items in the workflow, and improving the workflow. It also defines four flow metrics: work in progress, throughput, work item age and cycle time. Version 2025.5 was updated on May 1, 2025.
Are the change management principles different from the service delivery principles?
Yes. The three change management principles describe how to introduce and evolve Kanban in a team: start with what you do now, pursue evolutionary change and encourage leadership at all levels. The three service delivery principles cover how the team serves its customers and reviews its policies.
Is limiting WIP a principle or a practice?
It is a practice. You can check it on the board by looking at a number and a column. The principle behind it is evolutionary change: set the limit close to what you do now, then lower it step by step.
