Kanban WIP Limits for Spec-Driven Agentic Development

Traditional WIP limits in Scrum with Kanban are designed to stabilize team flow, but in the era of AI-assisted development, they have become the critical regulatory mechanism for the entire delivery system. When coding is 10x’ed by AI tools, the bottleneck immediately shifts downstream to code review, testing, and product validation: a phenomenon I call “acceleration whiplash.”

Simply generating code faster doesn’t mean you are delivering value faster. In this updated guide, we explore how Scrum teams must adapt their WIP limit strategies (the what, when, who, and how) to prevent AI-generated noise from overwhelming human gates and ensure that speed actually translates to business impact.

One of the key Kanban practices is limiting Work in Progress. While this practice traditionally aims to stabilize workflow and reduce cycle times, its role has changed dramatically with the rise of AI-assisted coding tools. When developers use Copilots or LLM code generators, the time it takes to move a feature from “In Progress” to “Ready for Review” drops significantly. Writing code becomes essentially frictionless.

But this speed is highly uneven. While code generation accelerates, the human-bound stages of software development (such as architectural review, E2E testing, product discovery, and user validation) cannot scale at the same rate. This creates a severe queue at the review gate, resulting in larger pull requests waiting for human eyes or being approved without real understanding. This is “acceleration whiplash” in action. It is a system-level flow problem, not a tooling problem. Without strict WIP limits, AI speed simply piles up inventory and slows down overall value delivery.

Spec-driven development does not remove this problem. It changes its shape. You write a spec, an agent implements against it, and you review what comes back. That loop runs fast enough that one person can keep three or four of them going at once, which is the whole appeal and also the trap.

Every running loop is work in progress. Every one of them ends in a diff somebody has to read. The unit of WIP moved: it is not the Jira card any more, it is the spec in flight. If you have four specs running and each returns a few hundred lines, you have not built a faster team. You have built a queue in front of yourself, and you are the constraint.

So the limits that matter are the ones on how many specs are open at once and how many agent-generated changes are sitting unreviewed. Limiting the Doing column on a board nobody looks at will not help you.

In a classic Scrum with Kanban setup, Developers own the Sprint Backlog workflow, which means they traditionally set and own their internal WIP limits. If the team is using Kanban to visualize and manage their Sprint flow, this remains the starting point. They monitor bottlenecks, adjust limits, and ensure they are swarming on active work rather than starting new tickets.

However, because AI tools shift the system constraints so rapidly, a team-level view is no longer sufficient. Product Owners and Developers must co-design the end-to-end flow boundaries. Without these shared limits, the high-speed engineering engine quickly runs out of ready, high-value work: a problem known as upstream starvation. Developers, finding themselves with empty hands, are tempted to pull low-value, unvalidated backlog items just to stay busy. This results in “AI theater,” where the engineering factory runs at maximum capacity to build nice-to-haves that are weakly connected to strategic business outcomes.

A common challenge for Scrum teams is how to handle mid-Sprint interruptions or high-priority requests. In a standard Kanban system, the policy is simple: do not change WIP limits on a whim. If an urgent item is pulled into the Sprint Backlog, it should count against the existing limit. If the team is already at their capacity, they must wait for a slot to free up or treat the exception as a visible policy breach to be analyzed during the Retrospective.

In the AI era, the temptation to bypass this discipline is intense. When a developer can use an LLM to write a “quick fix” in five minutes, it feels harmless to bypass the WIP limit. But that five-minute code generation still carries significant downstream costs: human cognitive load for code reviews, automated regression testing, deployment pipelines, and business validation. Keeping WIP limits rigid forces the team to confront the true cost of these interruptions. It prevents the system from being quietly flooded with half-done, uncoordinated code changes.

To manage flow in the age of AI acceleration, Scrum teams need to rethink their WIP limit strategies. Here are three practical approaches:

First, place strict WIP limits on the “Ready for Review” or “QA” columns. When coding speed increases, the queue in these columns will naturally explode. Enforcing a low limit here forces developers to stop writing new code and swarm on testing and reviewing existing PRs.

Second, leverage the time saved by AI to pair and swarm continuously. Instead of five developers working on five separate tickets with their own AI assistants, have them work in pairs or trios. Use the extra capacity to run continuous reviews and quality checks, keeping active WIP ultra-low and reducing handoffs.

Third, apply a strict WIP limit to the “Refinement” stage. Do not feed the high-speed development engine with unvalidated ideas. By limiting the work in flight during product discovery, you ensure that developers are only pulling specs that have clear evidence of business value.

Fourth, if you are running agents against specs, cap the specs. One or two in flight per person is usually the honest number, and it is lower than people expect. The constraint is not how many the agents can handle. It is how many finished diffs you can actually read carefully in a day.

Optimizing developer speed with Copilots while ignoring downstream constraints is a classic example of local optimization. It builds local speed but slows the overall value stream, leading to high activity and zero business impact.

If you are struggling with these bottlenecks, the answer is not more AI tools: it is a redesign of your operating model to ensure that speed actually translates to value. Managing flow at the team level is the fractal starting point for managing it at the portfolio level.

If you are ready to move beyond AI theater and align your development operating model for actual business impact, let’s talk.