Kanban Metrics in the Age of AI

There are some unspoken thoughts creeping into many delivery conversations lately.

If developers can generate code faster, test faster, produce documentation faster, then surely delivery becomes more predictable as a result?

And forecasting becomes … easier? Surely flow improves automatically?

It’s an appealing idea but it’s also wrong.
Let me explain.

AI is speeding up the wrong (or random) part of the system

Most AI adoption today is happening at the team level. There is a reason for that. AI is technology driven and it is best understood by engineers.

Developers are using tools like Copilot or Claude to produce decent code faster, or generate tests and maybe explore different solutions.

This is very real progress and it certainly matters. But it only affects one part of the system- active work.


And active work is rarely where delivery systems spend most of their time. In fact it hasn’t been the bottleneck in the last 10-15 teams I’ve worked with.

This isn’t just my perception. It’s something DORA research has been pointing to for some time already.


Any improvements in local efficiency like faster coding, better tooling, higher individual productivity, don’t automatically translate into better system outcomes. In fact, they can make things worse if the surrounding system isn’t able to absorb the increased throughput.


The way most organisations use AI nowadays is amplifying exactly that effect. It increases the rate at which work enters the system, but it does not improve how that work flows through it.


Let’s talk about the part AI doesn’t fix

If you look at a typical Software Kanban system, you will find that most elapsed time is not spent doing coding/engineering work.


Instead we have a ton of data showing that it is spent:

•     waiting for reviews
•     waiting for decisions
•     waiting on dependencies
•     waiting for other teams
•     waiting for priorities to become clear

Or in other words, it’s spent in queues.

At present, AI can make the doing faster but it does nothing about the waiting. Some will say: it can speed up reviews? it can speed up decisions? etc. but in truth all these don’t really need AI to happen faster and use of AI does not guarantee flow will be improved.


Waiting is something we solve by measuring and optimising flow. Any new technology is exciting but here’s the uncomfortable consequence of the current most common use of AI: The faster execution becomes, the more visible and more painful the waiting becomes.


Why flow gets worse before it gets better

Imagine we have two teams that become faster thanks to AI, but there is also a third team involved in completing the work that doesn’t get faster. What happens then?


Work piles up at the slowest point. So queues grow and work ages and forecasts degrade.


From the outside, it looks like things should be improving. After all, productivity is up.

But from a flow perspective, the system has become more unbalanced and forecasts more unstable.


AI has optimised the activities that were already fast but did nothing for the bottlenecks.


Why Kanban metrics become essential


One of the things I spend a lot of time explaining is that Kanban metrics were never about measuring effort. They are about understanding flow.

And flow is exactly what AI does not manage for you.
In fact, as systems become faster and more complex, you need better signals, not fewer.


You need to know:
    •    where work is ageing
    •    where queues are forming
    •    where WIP is exceeding capacity
    •    where blockers are accumulating
    •    how throughput is changing


Without that, AI simply helps you go faster… in the wrong direction.


A practical way to see the issue


Recently, I was delighted to discover a simple exercise proposed by Prateek Singh which illustrates the point.

Take your Kanban board as it is and look at the exit criteria for each column. These are the rules that define when work can move forward.


Note: if you don’t have exit criteria go and check my Kanban metrics series now!


Looking at your exit criteria ask:

“Can AI assist with this?”


You’ll likely find that a large proportion of those criteria can be supported by existing tools or practices like code reviews, tests, static analysis, documentation, etc.


Then have a look at what remains and you will likely find things such as approvals, prioritisation decisions, dependency coordination, readiness for release or alignment across teams.


These are not technical problems but system problems. It is unlikely that you would want to use AI to solve them. But they are usually where flow slows down.


What about forecasting in the new age?


Most organisations that share their AI adoption strategies seem to be approaching it at the bottom via providing tooling for individual contributors and at the top with their enterprise AI strategy.

They rarely talk about solving specific problems via initiatives, meeting user needs via new features or making changes to enable cross-team flow.


Yes, you guessed it - this is where delivery delays actually live.

A quick reminder of what typically causes delivery problems - a certain team is overloaded or another team has different priorities or dependencies weren’t visible early enough or decisions took too long, etc.


AI does not automatically resolve these issues.

When execution gets faster, variability increases. This happens automatically because work enters the system faster which leads to queues forming quickly and bottlenecks shifting fast.


As a result traditional, estimate-based forecasting becomes even less reliable while Kanban forecasting becomes more valuable because it still reflects what is actually happening, not what was planned or estimated.


The local optimisation risk


One of the biggest dangers of AI adoption is local optimisation.
When you focus on improving developer productivity and team throughput but you don’t manage the system as a whole this results in longer queues, more ageing or blocked work and less predictable outcomes.


The DORA reports have consistently demonstrated that high-performing organisations optimise for stability and flow, i.e. reducing batch size, limiting work in progress, and improving system-level feedback loops.


AI tools, on their own, push in the opposite direction. They increase output at the edges of the system. Without flow control, that output accumulates as inventory, delay, and coordination overhead.
Feels like we’re back where we started all those years ago (sigh).


A different way to think about AI and Kanban


Instead of asking: “How can AI replace parts of our process?”

Try asking: “Where can AI support flow, and where do we still need human judgement?”


Some parts of the system will become faster, more automated and perhaps consistent while other parts will remain organisational, contextual or dependent on judgement.


Kanban signals help you distinguish between the two types.

If you’re leading delivery in an AI-enabled environment, the challenge is not adopting tools but maintaining system awareness.


When the system evolves faster than before, clear signals, are essential to keep it stable.


What about AI readiness?


A lot of current thinking about AI adoption focuses on tooling. Making sure teams have access to coding assistants, AI for testing, documentation, or analysis. Are they adopting the latest models?


From a system perspective, the introduction of AI is less about how fast work can be produced, and more about whether the system can absorb and flow that work effectively.


The DORA research consistently shows that performance is not defined by how quickly changes are made, but by how reliably they move through the system and reach users.


In that sense, AI doesn’t reduce the need for flow management because the cost of getting flow wrong increases as speed increases.


A system that cannot manage WIP, ageing, and dependencies will struggle more in an AI-enabled world.


The rest is silence


It is clear by now that AI will change how work gets done but it will not change the fundamental dynamics of how work flows through a system.


If you think that queues or dependencies will cease to exist or that you’ll never wait on decisions again it might be time to pause and reflect.


I think that these factors will matter more as execution speeds increase.
Kanban metrics are not a legacy practice that AI will replace. They are not competing with AI. They give you the signals that can help you make AI usable at the system level.