Planejamento e estimativa de sprint na era da IA

Times que adotaram IA no desenvolvimento costumam manter a cerimônia de planejamento exatamente como era e depois estranhar que as estimativas pioraram. Não é impressão: a IA mexe justamente na variável que a estimativa por analogia assume estável.

Por que a estimativa piora antes de melhorar

Estimar por pontos funciona porque o time compara a tarefa nova com tarefas parecidas já entregues. Isso pressupõe que o custo de uma tarefa de determinado tipo é razoavelmente previsível.

A IA aumenta a dispersão desse custo. A mesma classificação de esforço agora cobre casos em que o assistente resolve quase tudo e casos em que ele atrapalha, e o que decide não é a complexidade aparente: é quão novo é o código, quanto contexto implícito existe e quão verificável é o resultado.

Resultado: a média até pode melhorar, mas o intervalo fica tão largo que o número perde utilidade para compromisso.

Estime tipo de tarefa, não só tamanho

Um ajuste barato e eficaz é acrescentar uma dimensão à conversa de planejamento: além de "quão grande", perguntar "quanto disso é território conhecido?".

Três faixas bastam:

• Verde. Código novo, padrão comum, resultado verificável por teste. Aqui a IA ajuda mais e a estimativa encolhe com segurança.
• Amarelo. Código existente com boa cobertura de teste. Ganho moderado, estimativa parecida com a histórica.
• Vermelho. Código central, antigo, com regra de negócio implícita e pouca cobertura. Aqui a IA pode custar tempo, e a estimativa não deve encolher.

Essa classificação leva um minuto por item e explica a maior parte da variação que hoje aparece como "erramos a estimativa".

O Scrum não pede pontos

Vale lembrar o que o Guia do Scrum realmente exige do planejamento: definir por que a sprint tem valor, o que pode ser entregue e como o trabalho será feito. Ele não prescreve pontos de história, nem velocity, nem planning poker.

Isso abre espaço para uma escolha que muitos times adiam: quando a previsibilidade do item cai, contar itens pequenos costuma prever melhor do que somar pontos de itens grandes. Fatiar mais e medir vazão é mais robusto à variação que a IA introduziu.

Deixe o ritmo falar mais alto que a estimativa

O Manifesto Ágil já colocava software funcionando acima de documentação e resposta a mudança acima de seguir um plano. Métrica de fluxo está mais alinhada a isso do que precisão de estimativa.

As quatro métricas da DORA continuam sendo o melhor conjunto pequeno para isso: tempo de lead para mudança, frequência de implantação, taxa de falha em mudanças e tempo para restaurar serviço. Elas capturam se o time está entregando com segurança, que é a pergunta real por trás de "a sprint coube?".

Um detalhe importante ao adotar IA: olhe as quatro juntas. Entregar mais rápido com taxa de falha subindo não é ganho, é dívida sendo transferida para o time de plantão.

Onde a IA ajuda na cerimônia em si

Sem transformar planejamento em teatro de automação, três usos se pagam:

• Fatiamento. Dar o item grande ao modelo e pedir três decomposições verticais diferentes, cada uma entregando valor de ponta a ponta. Serve como ponto de partida, não como decisão.
• Levantamento de risco. Pedir a lista de suposições implícitas e casos de borda do item. Bom para sair do "parecia simples".
• Contexto de código. Perguntar quais arquivos e integrações o item provavelmente toca, para classificar verde, amarelo ou vermelho com mais informação.

O que não funciona é pedir estimativa ao modelo. Ele não conhece o seu débito técnico, a sua fila de review, nem a pessoa que está de férias.

Cuide da carga cognitiva

O trabalho sobre experiência de desenvolvimento propõe olhar três dimensões: ciclos de feedback, carga cognitiva e estado de fluxo. IA mexe nas três, e nem sempre a favor.

Revisar código que você não escreveu tem carga cognitiva alta. Um time que gera muito mais código do que revisava antes sente isso primeiro como cansaço, depois como queda de qualidade. Planejamento precisa reservar capacidade de revisão, não só capacidade de escrita.

O que isso significa para o seu time

Adicione a classificação verde, amarelo e vermelho ao refinamento por três sprints e compare o erro de estimativa por faixa. Provavelmente você vai descobrir que o problema estava concentrado no vermelho.

Reserve capacidade explícita de revisão na sprint, proporcional ao volume que a IA passou a gerar. E acompanhe as quatro métricas da DORA lado a lado, para não comemorar velocidade que está sendo paga em estabilidade.