You Need Tighter WIP Limits With AI
In a recent class, we were discussing how teams are using AI and finishing coding faster but still missing Sprint Goals. How can these things both be true?
That question gets to the heart of a shift many Scrum Teams are experiencing right now. AI has changed the bottleneck. Coding is no longer the constraint it once was. Yet many teams respond by increasing work in progress instead of reducing it. The thinking goes: “We can handle more work now, so let’s pull more in.”
The result is pretty predictable. When you work on too many things at once, you end up context switching and delivering value more slowly.
Why? Claude Code may be able to crank out code in a few seconds or a minute or two, but we still have a human in the middle who needs to do a code review. We still need to give feedback on whether what was delivered meets the business needs. All of that takes focus. Jumping back and forth between tasks slows people down. When you switch from one item to another, it takes a few minutes just to get back up to speed.
Where to Focus Your WIP Limits Now
To get things done faster, limit your WIP. Here’s where to focus those limits now that AI is part of the team.
Make code review visible on the board and put a limit on it
Development is moving much faster, so the new bottleneck is often code review. Reviewing AI-generated code takes real focus. AI often puts code in many different places, and the result can feel similar to work from a first-year programmer. You need to walk through the logic to make sure there are no unexpected negative impacts. Add a clear Code Review column and set a tight limit on it.
Limit the other downstream steps
Testing, deployment, and any waiting-for-feedback stages also need limits. Visualize these steps on the board and keep the limits low, especially on Ready to Deploy. This creates transparency on where work is piling up and helps finished work reach customers sooner so you can get feedback faster.
Run a simple experiment
Not convinced? Pick one or two downstream columns and deliberately lower their WIP limits for the next two Sprints. Measure cycle time, throughput, and customer satisfaction. With more discipline around delivery, teams often start focusing on the work that produces the best customer outcomes.
Conclusion
Scrum Teams succeed by inspecting what is actually happening and adapting. Faster coding is a gift only if the team also adjusts its limits so that finished, valuable Increments keep flowing.
The goal has never been to maximize the amount of code produced. The goal is to maximize the delivery of value through finished, usable Increments. Tighter, thoughtfully placed WIP limits remain one of the most effective ways to do that, especially now that coding itself is no longer the slowest step.
