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.
Por qué importa
En gestión de proyectos casi todo lo que se discute como problema técnico es en realidad un problema de expectativas mal negociadas al principio. Alcance, plazo y costo se pactaron en un momento en que nadie tenía la información suficiente, y después nadie quiso reabrir la conversación.
Lo que yo miro primero en un caso así no es el plan, es la frecuencia con la que se corrige. Un proyecto que replanifica cada mes con datos frescos llega mucho más cerca que uno que defiende durante un año la línea base que firmó cuando menos sabía.
Lo que suele salir mal
Lo que más veo fallar es el patrocinador ausente. Firma el inicio, aparece en la foto y después no vuelve hasta que hay un problema. Sin alguien con poder real que despeje obstáculos cada quince días, el jefe de proyecto termina negociando de igual a igual con áreas que no le reportan, y pierde.
Qué mirar
- Cómo se estimó y qué tan cerca estuvieron las estimaciones anteriores de la misma organización.
- Quién es el patrocinador y con qué frecuencia real aparece — no en el organigrama, en la agenda.
- Si el reporte de estado muestra proyectos en rojo: un portafolio todo en verde es un portafolio sin información.
Cómo leo esta entrada
La forma en que yo bajaría esto a tierra es reduciendo el tamaño de las entregas. Un proyecto de dieciocho meses sin nada visible antes del mes doce es una apuesta, no un plan. Prefiero seis entregas que sirvan por separado, aunque el total tarde un poco más, porque cada una corrige el rumbo.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
