Limit Work in Progress on AI and Software Teams

This is the work-admission test I wish more AI and software teams used.

Most teams do not become overloaded because nobody can see the backlog. They become overloaded because visible demand is mistaken for work that should start now. A roadmap item enters discovery, a prototype enters development, a model change enters evaluation, and three generated pull requests enter review. Each decision sounds reasonable in isolation. Together they create a system with more beginnings than endings.

The resulting delay is easy to misread. Managers see people waiting and assign another task. Stakeholders see slow delivery and increase urgency. Engineers see a blocked review and begin a side project. AI tools make the pattern worse by producing code, analysis, tests, and documents faster than the team can validate or integrate them.

The useful response is not to ask everyone to move faster. It is to control how much work is allowed to be active at once.

A work-in-progress limit, usually shortened to WIP limit, is a policy that caps the number of items inside part of a workflow. It turns capacity from an optimistic feeling into an explicit operating constraint. When the limit is reached, the default action is to finish, unblock, review, or improve the system—not quietly add another commitment.

Starting work is a capacity decision

A backlog can contain hundreds of ideas without harming delivery. Active work is different. The moment an item starts, it creates obligations: people must remember its context, coordinate decisions, maintain branches or environments, answer questions, review outputs, and explain its status.

This distinction matters because technical inventory is mostly invisible. A factory can see physical material accumulating. A software team may have unfinished work spread across tickets, documents, feature branches, experiments, notebooks, Slack threads, model configurations, and private task lists. The board shows six items while the real system carries twenty.

DORA’s guidance on work-in-process limits recommends prioritizing work, limiting how much people take on, and finishing a small number of high-priority items. It also warns teams to count invisible work and account for production support, meetings, and technical debt when setting limits.

That makes admission the first management decision. Before asking who can start a request, ask whether the workflow can accept another obligation without slowing everything already inside it.

This is different from a priority framework. Prioritization ranks demand. Admission control decides which ranked work is allowed to consume capacity now. A perfectly ordered backlog can still overwhelm a team if its first fifteen items all begin together.

AI increases arrivals without increasing judgment

Generative AI changes the arrival rate of technical work. A coding agent can prepare several changes while one engineer used to prepare one. An analyst can generate multiple query variants and narratives. A product team can turn one idea into requirements, mockups, acceptance criteria, and tickets in minutes.

Some of that speed is valuable. But the rest of the workflow does not accelerate automatically.

Generated code still needs tests, security review, architecture judgment, and integration. A RAG change still needs retrieval and answer evaluation. A new agent tool still needs permission boundaries, failure handling, tracing, and human approval rules. A polished analysis still needs verified definitions and data quality. Faster creation can move the constraint toward the people who can judge whether the output is safe and useful.

Google Cloud’s 2025 DORA research describes AI as an amplifier of the existing system and argues that value stream management helps convert local productivity into product performance. Its current guidance on working in small batches is especially relevant: AI tools may encourage large generated changes, even though machine-generated code can impose substantial review effort.

So an AI team should not set its development limit only by how quickly people or agents can create output. It should set limits around the scarce stage: evaluation, review, security approval, domain validation, or deployment.

If two senior engineers can responsibly review only four meaningful AI-assisted changes in a week, generating twelve does not create eight extra units of progress. It creates a queue, longer feedback time, merge conflicts, stale assumptions, and pressure to approve work too quickly.

Set limits around the workflow, not each person

A personal rule such as “one task per engineer” can help focus, but it does not manage the whole system. Work moves through stages, and the bottleneck may sit between people rather than with one person.

Consider an internal support assistant:

1. Product clarifies the user case.
2. Data owners prepare approved knowledge.
3. Engineers change retrieval or prompts.
4. Evaluators run test sets and inspect traces.
5. Security reviews permissions and sensitive-data behavior.
6. Operations deploys and watches production feedback.

Allowing unlimited work into engineering will not help if evaluation can handle only two changes at once. The correct response is not to keep engineers “utilized” with more features. It is to swarm on evaluation, improve its tooling, make changes smaller, or temporarily spend capacity elsewhere without pretending more assistant features are active.

The official Kanban guide explains that limits can apply to a state, a person, a service class, a lane, or the entire system. The design should reflect the real flow. There is no universal number.

Start with a defensible limit, then learn from it. If three people actively implement changes, an initial implementation limit of three may be reasonable. If one qualified reviewer is available, the review column may need a limit of one or two. Include completed work waiting for the next step; a card awaiting review still occupies the system.

The limit should feel slightly uncomfortable. If it never constrains a decision, it is probably documenting current overload rather than changing it.

A full lane is a signal to help

Teams sometimes treat a WIP limit as a bureaucratic stop sign. Someone finishes their piece, sees that the next lane is full, and waits. Management then raises the limit because idle time looks wasteful.

That misses the point.

A full lane reveals where collective attention is needed. The person with capacity can review a change, improve automated checks, reproduce a failure, clarify acceptance criteria, reduce the batch size, document a decision, or help remove a dependency. If none of those actions is possible, the delay is still useful evidence about team design.

This is why maximizing individual utilization can damage flow. Keeping every specialist busy produces local efficiency while work waits at handoffs. A team delivers through the whole path, not through the busiest column.

DORA’s visibility-of-work guidance recommends examining lead time, process time, and the percentage of work received complete and accurate. Those measures distinguish working time from waiting and expose rework passed downstream. They are more informative than ticket counts alone.

For AI work, add evidence appropriate to the workflow:

• time waiting for evaluation or human approval
• number of changes sharing the same evaluation environment
• percentage of generated changes returned for rework
• age of experiments with no continuation decision
• reviewer time per accepted change
• production defects linked to hurried validation

The objective is not to make the dashboard sophisticated. It is to see where work stops moving and decide what the team will change.

Urgent work needs a policy before the emergency

Every technical team has legitimate interruptions. A production outage, exposed credential, critical data error, or harmful AI behavior cannot wait politely behind roadmap work.

The danger is creating an expedite lane that accepts anything backed by a senior title or an anxious message. Soon the exception becomes the main workflow, active items are repeatedly abandoned, and nobody believes the WIP limits.

Define the emergency policy in advance. It should answer:

• Which consequences qualify for expedited treatment?
• Who can make that classification?
• What active item pauses when the expedite slot is occupied?
• Who records the interruption and its cost?
• When does the item return to normal flow?
• Which recurring emergencies trigger a root-cause review?

Keep the expedite limit very small—often one for a team. If a second emergency arrives, leaders must compare them explicitly rather than declaring both top priority.

This complements the broader guidance in How AI Teams Protect Important Work From Daily Noise. That note helps distinguish consequential work from distraction. A WIP policy makes the consequence operational: important demand waits until capacity exists, or leadership names what it replaces.

Do not hide commitments outside the board

WIP limits fail when managers apply them only to delivery tickets. Real technical work includes incident response, stakeholder support, hiring, mentoring, compliance evidence, platform maintenance, data investigations, and recurring meetings. AI work adds evaluation design, prompt and model regression checks, cost analysis, permission reviews, and trace inspection.

If these activities consume meaningful capacity, represent them. Not every short conversation needs a card, but recurring or multi-hour obligations cannot remain invisible while the team claims to have spare capacity.

The same rule applies to blocked work. A blocked item is not free. It retains context, creates follow-up, and may become urgent later. Keep it inside the limit unless the team explicitly stops it, preserves what was learned, and returns it to the backlog.

This is a leadership discipline because stakeholders often prefer the appearance that their request is underway. “Started” sounds reassuring. In reality, a request waiting among ten active commitments may receive worse service than one honestly held in a prioritized queue.

For a fuller treatment of hidden capacity, bottlenecks, and reserve work, see Manage AI Team Capacity Without Burning Budget. The narrower lesson here is that a limit has no credibility when obligations can bypass it.

Run a two-week WIP experiment

Teams do not need a transformation program to test this idea. Run a small experiment for two weeks.

First, map the actual path from accepted request to usable outcome. Use the stages the work really passes through, including evaluation, approval, deployment, or adoption. A generic “To do / Doing / Done” board often hides the constraint.

Second, count everything currently active. Include blocked items and substantial untracked obligations. Decide which work to finish, which to stop, and which to return to the queue before setting limits.

Third, place an initial limit on the stage with the clearest congestion. Do not debate the perfect number for weeks. Choose one based on available capacity and make it easy to revise after evidence.

Fourth, establish a replenishment point. Once capacity opens, the team pulls the highest-priority ready item. A ready item has an owner, a useful outcome, enough context, known constraints, and a next decision. Pulling vague work merely changes where it waits.

Fifth, record four measures: items completed, end-to-end lead time, blocked age, and returned work. Add review time or evaluation wait when AI-generated output is central.

Finally, review the exceptions. When did the team violate the limit? Was the reason legitimate? Did the limit expose missing test automation, overloaded expertise, poor scoping, or an external dependency? Change the process before increasing the number.

In my teaching, I often see the individual version of this problem: learners collect several parallel courses and exercises, yet the deepest learning begins when they stay with one imperfect project long enough to debug it. Team delivery follows a similar principle. Starting creates the feeling of movement; finishing produces feedback.

WIP limits make priorities believable

A work-in-progress limit will not repair a weak strategy. It cannot choose the right product, create missing expertise, or remove every dependency. It can make those problems harder to conceal.

When the limit is full, a new request forces a useful conversation. Is this more important than what is active? Should something stop? Can we help the bottleneck? Is the new work truly ready? Does the team have validation capacity, not merely generation capacity?

Those questions are particularly important now. AI can make the front of a technical workflow look extraordinarily fast while review, integration, governance, and user learning remain scarce. The answer is not to suppress useful tools. It is to design the flow around the whole responsibility.

Keep the backlog broad if discovery needs it. Keep active work narrow. Let capacity pull the next ready commitment. Measure endings, waiting, and rework—not just starts.

That is how a team turns “these are our priorities” from a presentation into an operating fact.