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.
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.
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 NowTo get things done faster, limit your WIP. Here’s where to focus those limits now that AI is part of the team.
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.
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.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 12/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
In project management, nearly everything discussed as a technical problem is really a problem of expectations badly negotiated at the start. Scope, time and cost were agreed at a moment when nobody had enough information, and afterwards nobody wanted to reopen the conversation.
What I look at first in a case like this is not the plan, it is how often it gets corrected. A project that replans every month with fresh data lands far closer than one that spends a year defending the baseline it signed when it knew least.
What usually goes wrong
What I see fail most is the absent sponsor. They sign the kick-off, appear in the photo, and do not come back until there is a problem. Without somebody with real authority clearing obstacles every fortnight, the project manager ends up negotiating as an equal with areas that do not report to them, and loses.
What to watch
- How it was estimated and how close the same organisation's previous estimates turned out to be.
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
- Whether the status report shows any red projects: an all-green portfolio is a portfolio without information.
How I read this entry
The way I would bring this down to earth is by shrinking the size of the deliveries. An eighteen-month project with nothing visible before month twelve is a bet, not a plan. I would rather have six deliveries that stand on their own, even if the total takes a little longer, because each one corrects the course.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
