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 que importa
Em gestão de projetos, quase tudo o que se discute como problema técnico é na verdade um problema de expectativas mal negociadas no começo. Escopo, prazo e custo foram acordados num momento em que ninguém tinha informação suficiente, e depois ninguém quis reabrir a conversa.
O que eu olho primeiro num caso assim não é o plano, é a frequência com que ele é corrigido. Um projeto que replaneja todo mês com dados frescos chega muito mais perto que um que passa um ano defendendo a linha de base que assinou quando menos sabia.
O que costuma dar errado
O que mais vejo falhar é o patrocinador ausente. Assina o início, aparece na foto e depois só volta quando há problema. Sem alguém com poder real removendo obstáculos a cada quinze dias, o gerente de projetos acaba negociando de igual para igual com áreas que não lhe reportam, e perde.
O que observar
- Como foi estimado e quão perto estiveram as estimativas anteriores da mesma organização.
- Quem é o patrocinador e com que frequência real aparece — não no organograma, na agenda.
- Se o relatório de status mostra projetos em vermelho: um portfólio todo verde é um portfólio sem informação.
Como leio esta publicação
A forma como eu traria isto ao chão é reduzindo o tamanho das entregas. Um projeto de dezoito meses sem nada visível antes do mês doze é uma aposta, não um plano. Prefiro seis entregas que sirvam separadamente, mesmo que o total demore um pouco mais, porque cada uma corrige o rumo.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
