ITIL and Kanban: How to Use Them Together

ITIL and Kanban work best together, not against each other. ITIL gives you a system for governing, delivering, supporting, and improving digital products and services. Kanban makes the work inside that system visible, limits overload, and shows where requests are waiting. If ITIL tells you what the service system must achieve, Kanban shows whether work can actually flow through it.

That distinction matters because the common “ITIL vs Kanban” framing creates a false choice. You do not replace service governance with a board of cards, and you do not fix a congested queue by writing another process document. You use each method for the job it can do.

Quick answer: Use ITIL to define service outcomes, practices, governance, responsibilities, and continual improvement. Use Kanban to visualize a selected workflow, control work in progress, manage classes of service, and measure flow. Start with one service value stream, not an organization-wide rollout.

ITIL and Kanban solve different problems

ITIL is broad guidance for managing digital products and services. Kanban is a method for improving the flow of knowledge work through an existing way of working. One gives the operating context; the other exposes how work behaves inside a chosen part of it.

Dimension	ITIL	Kanban
Primary job	Manage and improve digital products and services	Improve the flow of work through a service
Scope	Value system, lifecycle, governance, practices, products, and services	One workflow, service, team, or network of services
Unit you observe	Products, services, practices, value streams, and outcomes	Work items moving from commitment to delivery
Useful signals	Value, outcomes, service performance, risk, experience, and improvement	WIP, lead time, delivery rate, queues, blockers, and demand types
What it does not solve alone	Live congestion and capacity inside a specific workflow	Enterprise governance, service strategy, and the full management system

Kanban is deliberately evolutionary. The official Kanban guide says to apply the method on top of the workflow you already have. That makes it a natural fit for ITIL environments: you can improve flow without pretending that every service practice must be redesigned at once.

What changed in ITIL

The old 5-stage ITIL v3 service lifecycle is history, not the current model. It remains useful background for older documentation, but teaching it as present-day ITIL creates the wrong mental picture.

• ITIL 4 moved the framework toward a Service Value System, a service value chain, guiding principles, practices, governance, and continual improvement.
• ITIL (Version 5) began a phased rollout in 2026. It expands the emphasis from traditional IT service management to end-to-end digital product and service management.
• ITIL 4 remains available during the transition. Existing ITIL 4 knowledge and certifications do not become worthless because a new version exists.
• Flow is now harder to ignore. Current ITIL product guidance explicitly discusses integrated value streams, flow optimization, evidence-based decisions, and a product and service lifecycle from discovery to support.

PeopleCert describes ITIL (Version 5) as a gradual evolution rather than a reset. That is the sensible way to use it here. Keep the governance and service-management discipline, then add a sharper view of actual work and delay.

How to combine ITIL and Kanban

Do not begin by building a board for every ITIL practice. Begin with one service whose demand, delays, or handoffs are causing pain. Then make that service observable.

Map one value stream

Choose a workflow with a clear customer and a clear delivery point. Incident resolution, service-request fulfillment, problem investigation, access provisioning, and change enablement are reasonable candidates.

• Name the demand that enters the service.
• Identify the commitment point, where the team accepts responsibility for delivery.
• Identify the delivery point, where the customer receives the intended outcome.
• Show queues, approval waits, external dependencies, and rework instead of hiding them inside a generic “In progress” column.

This is the same practical instinct behind a sound Agile process: inspect the real system of work rather than forcing people to perform a framework.

Define work items and policies

A board becomes useful when every column and work type has an explicit meaning. Define what may enter, what “ready” means, who can pull it, what evidence is required to move it, and what counts as complete.

• Work item types: incidents, service requests, problems, standard changes, improvement items, or another set that reflects actual demand.
• Classes of service: ordinary work, fixed-date work, and a tightly controlled expedite class for genuine emergencies.
• Pull criteria: the conditions that let the next stage accept work.
• Blocker policy: how a blocked item is marked, escalated, reviewed, and unblocked.

Without these policies, the board records opinions. With them, it records operational decisions.

Set WIP limits where overload occurs

Work in progress limits protect flow by stopping the system from starting more work than it can finish. The first limit does not need to be perfect. It needs to be explicit, observed, and adjusted from evidence.

• Place limits on active stages, not only on the total board.
• When a stage reaches its limit, help finish or unblock work before pulling another item.
• Do not create a permanent escape lane for every “urgent” request.
• Review whether the limit reveals a capacity problem, a policy problem, or a dependency outside the team.

WIP limits are where Kanban stops being a prettier ticket queue. They force the uncomfortable but useful conversation about capacity.

Measure flow and improve

Use the board and its data as an input to continual improvement. Review the current state, choose a measurable target, change one part of the system, and compare the new result with the baseline.

The board is not the improvement. It is the instrument panel.

A service-desk Kanban example

Imagine a service-request workflow that currently disappears into one long queue. A useful first board might be:

Stage	Policy	Signal to watch
Requested	Demand has arrived but is not yet committed	Arrival rate and request type
Triage	Check scope, impact, information, ownership, and class of service	Age of untriaged work
Ready	Acceptance criteria and required information are complete	Queue size and oldest item
In progress	Owned and actively worked; WIP limit applies	Active WIP and blockers
Validate	Outcome is checked with the requester or against defined evidence	Rework and validation delay
Done	Delivery criteria are met and closure evidence is stored	Lead time and delivery rate

A major incident may use an expedite policy, but that policy must be rare and visible. Every expedited item delays ordinary work. Kanban makes that cost apparent instead of letting urgency silently consume the system.

If an external provider owns part of the flow, include that queue and its evidence. The same rule applies when evaluating managed IT services: outsourced work is still part of your service system, even when the cards cross an organizational boundary.

Metrics that reveal whether flow is improving

Kanban metrics should help you manage the service, not rank individuals. The official guide identifies WIP, lead time, and delivery rate as core measures. Add local signals only when they change a decision.

• Work in progress: How many committed items are inside the system or a selected stage right now?
• Lead time: How long does a work item take to travel from commitment to delivery?
• Delivery rate: How many items reach delivery in a defined period?
• Blocked time: How much elapsed time is lost to dependencies, missing information, or decisions?
• Demand by work type: Which requests consume capacity, and how variable is that mix?
• Rework: How often does supposedly finished work return to an active stage?

A shorter average can still hide a few painfully old items, so examine distributions and aging work as well as headline averages. The reader waiting 20 days does not care that the mean is 4.

Where the combination fails

Most failures come from adopting the vocabulary while protecting the old behavior.

• The board is only a task list. Work is visible, but there are no WIP limits, pull policies, or flow reviews.
• Every request is urgent. An unlimited expedite lane destroys predictability for the rest of the service.
• ITIL becomes a documentation project. Teams optimize templates and approvals while lead time and failure demand remain untouched.
• Kanban becomes a local team island. The team improves its board while supplier, governance, or approval queues remain invisible.
• People are measured for utilization. Keeping everyone busy increases queues. Flow improves when the system finishes valuable work, not when every person starts another item.
• No one owns the service outcome. A board cannot replace governance, risk decisions, funding, service ownership, or customer accountability.

This boundary is also why ITIL, Kanban, and governance frameworks such as COBIT and COSO should not be collapsed into one giant methodology. They operate at different levels. The useful work is connecting them without confusing their jobs.

The practical decision

Use ITIL and Kanban together when a service has defined responsibilities but still suffers from hidden queues, too much parallel work, unpredictable delivery, or weak feedback. ITIL supplies the management system. Kanban makes one part of that system observable and changeable.

Pick one high-friction workflow. Mark its commitment and delivery points. Define entry and exit policies. Set a first WIP limit. Measure lead time, delivery rate, WIP, and blockers for long enough to see the real pattern.

Then improve the system you can see.