Ágil com IA: Por Que Scrum Tradicional Não Serve Mais

Ágil com IA: Por Que Scrum Tradicional Não Serve Mais

Gestão ágil de projeto foi construída pra um mundo onde o escopo era mais ou menos previsível. Scrum, sprints de 2 semanas, planning poker, burndown chart. Tudo funciona até você estar gerenciando um projeto de IA — e aí 60% das premissas do ágil clássico quebram silenciosamente.

Este post é pra product manager, tech lead e scrum master que vão liderar projeto de IA pela primeira vez. Foi escrito em cima da experiência real de entregar projetos de IA em produção com times que até então faziam Scrum de software tradicional.

O que quebra quando você tenta rodar Scrum em projeto de IA

1. Estimativa em story points vira chute

No Scrum tradicional, você estima uma tarefa comparando com outra semelhante que o time já fez. Em projeto de IA, cada task traz uma incerteza nova: o modelo vai funcionar com esse dado? O prompt vai passar na validação? A integração vai ter latência aceitável?

Resultado: estimativa varia 5-10x da realidade. Time fica frustrado. Scrum master cobra "por que não bateu o sprint?". Ninguém tem a resposta honesta: porque não dava pra saber antes.

2. Critério de "pronto" fica indefinido

"Agente resolve 80% das dúvidas sem humano" parece critério claro. Só que no dia 15 o número tá em 72%. No dia 20, tá em 85%. No dia 22, caiu pra 78%. "Pronto" num modelo estatístico é probabilístico — e isso quebra a métrica binária (feito/não feito) do Scrum.

3. Tasks não são independentes

No software tradicional, você pode mover uma task entre sprints sem quebrar o resto. Em projeto de IA, um ajuste de prompt na task A muda o comportamento do agente na task B — que já estava "pronto". Você não tem testes automatizados que cubram comportamento estatístico.

O que fazer: ágil adaptado para IA

1. Substitua story points por "ciclos de validação"

Cada task de IA tem um custo em ciclos: quantas vezes precisa rodar o modelo, avaliar output humano, ajustar prompt, rodar de novo. Isso escala melhor que story points. Um ciclo grande pode levar 1 dia; um pequeno, 2 horas.

2. Sprints mais curtos — 1 semana

Sprint de 2 semanas é longo demais pra projeto de IA em construção. O modelo aprende (ou não) muito rápido. Sprint de 1 semana permite ajuste de rota sem comprometer grandes blocos de trabalho.

3. "Done" passa a ter dois níveis: técnico e estatístico

Técnico: código mergeado, testes passando, deploy em staging. Estatístico: métrica de qualidade acima de X% em uma janela de Y amostras. Os dois precisam estar verdes pra a task ir pra produção. Sem o nível estatístico, agente "pronto" pode chegar em produção e destruir métrica de negócio em uma semana.

4. Backlog tem coluna "hipótese"

Tarefa que depende de validar algo desconhecido (modelo novo, prompt novo, dado novo) não vai direto pro backlog tradicional. Vai pra coluna "hipótese" — com experimento específico que precisa rodar antes de virar task acionável.

5. Retrospectiva tem revisão de método, não só de entrega

A cada sprint, time revisa: nossa maneira de estimar está calibrando? Nossos ciclos de validação estão tamanho certo? Está sobrando tempo em experimento e faltando em integração? Método de gestão em projeto de IA precisa ajustar durante o projeto, não só depois.

Anti-padrões que matam projeto de IA gerenciado por Scrum clássico

• Cobrança de velocity crescente. Projeto de IA tem velocity não-linear — ciclos de descoberta seguidos de ciclos de produção. Gráfico crescente significa que o time parou de experimentar.
• Daily com "o que você entregou ontem" — sem espaço pra discutir hipóteses que não viraram task. Em projeto de IA, hipótese descartada também é progresso.
• Demo só de feature nova — sem mostrar variação de métrica ao longo do sprint. Time perde contexto de que está construindo sistema estatístico.
• Priorização por business value puro — sem considerar incerteza técnica. Task de alto valor mas alta incerteza precisa ciclo de validação antes, não execução direta.