Autor verificado Compartilhar
A armadilha está no método de medição que você herdou do passado — e que deixou de fazer sentido no momento em que seu time pegou a primeira ferramenta de IA.
Boa parte das empresas está inserido IA nos times de tecnologia. Os desenvolvedores estão usando Copilot, ChatGPT, Cursor, Claude Code, e por aí vai. Os analistas estão gerando código, testes, documentação em metade do tempo. A entrega está acelerando.
Mas na reunião de review, o gestor olha para o relatório e franze a testa: “os Story Points caíram esse mês.”
E aí começa o problema.
Esse texto é sobre uma armadilha silenciosa que está acontecendo em dezenas de times “ágeis” agora mesmo — e sobre como sair dela usando as métricas certas.
Story Points foram criados com um propósito bem definido: medir e equalizar a complexidade relativa dos entregáveis, não o esforço ou tempo absoluto. Quando o time diz que uma User Story vale 8 pontos, está dizendo que ela é mais complexa do que uma de 3 — não que vai levar X horas/dias.
Essa distinção sempre foi importante. Mas ela se torna crítica quando a IA entra em cena.
Uma tarefa de 8 pontos continua sendo de 8 pontos de complexidade. O que mudou foi o tempo que o desenvolvedor leva para resolvê-la. São conceitos diferentes.
O que acontece na prática? O time começa a usar IA. As tarefas ficam mais rápidas de fazer. Na próxima sessão de refinamento, as estimativas caem — porque o time inconscientemente começa a calibrar pelo esforço percebido, não pela complexidade inerente ao problema. Uma história que antes era 8 vira 3.
O velocity (soma de pontos por sprint) despenca.
O gestor olha para o gráfico e pensa: “o time regrediu?” Quando na verdade o time acelerou, mas a régua foi torta.
O Paradoxo da IA com Story Points
Quando a IA aumenta a capacidade de entrega, a tendência natural dos times é recalibrar suas estimativas para baixo. Isso faz o velocity cair — exatamente quando a produtividade real está subindo.
Gerenciar pelo velocity nesse contexto é como medir a velocidade de um carro olhando para o espelho retrovisor.
| Pergunta | Story Points respondem? | Métricas de fluxo respondem? |
|---|---|---|
| Quantas coisas o time entregou? | Não diretamente | ✓ Throughput |
| Em quanto tempo uma demanda sai? | Não | ✓ Lead Time |
| O time acelerou com IA? | Induz a erros | ✓ Throughput + Lead Time |
| Quantas coisas estão em andamento? | Não | ✓ WIP |
| O processo tem gargalos? | Não | ✓ Lead Time Breakdown |
| O tempo de espera está alto? | Não | ✓ Flow Efficiency |
| A complexidade dessa tarefa é alta? | ✓ Sim, para isso serve | Não é o objetivo |
Story Points não são inúteis. Eles continuam sendo úteis para priorização e planejamento relativo dentro de uma sprint. O problema é usar o somatório de pontos como indicador de produtividade — isso nunca foi o design da ferramenta, e se torna ainda mais enganoso agora.
O pilar das métricas de fluxo — metodologia consolidada pelo Kanban e amplamente usada por times de alta performance — responde exatamente às perguntas que o mundo com IA exige.
→ Throughput [Quantidade de itens entregues no período]
Número de work items finalizados por unidade de tempo (semana, sprint). Independente da complexidade de cada um. A pergunta é simples: quantas coisas o time entregou?
→ Lead Time [Tempo de ciclo da demanda]
Do momento em que o time assumiu o item até a entrega. Quando a IA aumenta a produtividade, esse número cai — e é exatamente aí que você enxerga o ganho real. Ps. obviamente você precisa mensurar a qualidade das entregas, pois aumento de velocidade e piora na qualidade é aumentar o número de retrabalho, gerando novos problemas e até mais complexos.
→ WIP (Work in Progress) [Trabalho em andamento]
Quantos itens estão em progresso ao mesmo tempo. Pelo princípio da Lei de Little, limitar o WIP reduz o Lead Time proporcionalmente.
→ Flow Efficiency [Eficiência do fluxo]
Quanto do Lead Time total é tempo de trabalho real vs. tempo de espera. Times médios ficam em torno de 15–30%. Com IA bem aplicada, esse índice sobe.
Você não precisa abandonar Story Points da noite para o dia. Mas precisa parar de usá-los como métrica de produtividade e começar a usar métricas de fluxo como o indicador principal. Aqui está um caminho em etapas:
Use este quadro para diagnosticar o que está acontecendo no seu time:
Sinais de alerta!
Sinais saudáveis
Existe um fenômeno natural e esperado quando a IA entra em cena: o time precisa de algumas semanas para recalibrar a escala de estimativas.
Durante esse período, o somatório de Story Points vai oscilar de forma não representativa. É exatamente nesse intervalo que você precisa focar no throughput e no Lead Time — porque eles continuam sendo confiáveis independente de como o time está estimando.
“Não existe implementação Kanban ruim. Existem práticas inadequadas para o momento da organização.”
Kanban Maturity Model — Kanban University
O mesmo vale aqui. Não existe uma forma “errada” de medir produtividade — existe uma forma inadequada para o contexto. E o contexto mudou quando a IA chegou.
Uma observação importante que costuma ser ignorada: a IA não acelera tudo igualmente.
Tarefas com código bem definido, padrões conhecidos e baixa ambiguidade: a IA acelera muito. Tarefas de exploração, decisão arquitetural, entendimento de domínio complexo, negociação com stakeholders: a IA ajuda, mas não transforma dramaticamente.
Isso significa que o impacto no Lead Time vai variar por tipo de item. Uma User Story de CRUD bem especificada pode ter seu Lead Time reduzido em 60%. Uma Story que envolve redesenho de um módulo legado pode não mudar muito.
→ Ação prática
Segmente seu scatterplot de Lead Time por tipo de item E por uso de IA (se conseguir rastrear). Isso vai revelar onde a IA está gerando mais impacto e onde o gargalo está fora do desenvolvimento em si — provavelmente em filas de revisão, aprovação ou deploy.
Essa mudança de métricas tem um componente humano e político. Gestores que estão acostumados com velocity precisam de uma narrativa clara para fazer essa transição sem resistência.
A narrativa mais eficaz que tenho visto funcionar:
“A IA está funcionando. Nosso time está entregando mais itens por sprint e mais rápido. O velocity caiu porque a ferramenta de estimativa que usávamos mede complexidade relativa — e o time naturalmente recalibrou quando o esforço mudou.
Para ter uma visão real do impacto, precisamos olhar para throughput (quantas entregas), Lead Time (em quanto tempo) e WIP (quantas coisas estão em andamento). São esses os números que mostram se estamos ficando mais eficientes.”
Apresente os dois períodos lado a lado: throughput médio antes e depois, Lead Time mediano antes e depois. Isso é mais convincente do que qualquer argumento teórico.
A chegada da IA no time não é só uma mudança de ferramenta. É uma mudança de regime de trabalho. E toda mudança de regime exige uma revisão das métricas — porque métricas são modelos, e todo modelo tem um contexto de validade.
Story Points continuam sendo úteis. Mas o velocity como proxy de produtividade perdeu muito de sua confiabilidade no mundo com IA (e até mesmo antes dela). O que substitui não é mais complexo — é mais honesto com o que realmente importa: quantas entregas de valor, em quanto tempo, com qual previsibilidade.
Throughput, Lead Time e WIP são as três métricas que respondem a essas perguntas de forma robusta. Não dependem de como o time estimou. Não dependem de quem fez o trabalho. Dependem apenas do que passou pelo sistema — e isso inclui a IA como aliada, não como distorção.
O time que primeiro fizer essa transição vai ter uma vantagem enorme: vai conseguir demonstrar o valor real da IA com dados, não com impressões. E vai conseguir identificar onde a IA ainda não está ajudando — que provavelmente é onde estão os maiores gargalos do processo.
Autor verificadoSenior Principal Agile Leader na Zallpy, com sólida experiência na definição e evolução de modelos ágeis escaláveis, sustentáveis e orientados à geração de valor. Atualmente atua como Senior Principal Agile Leader na Zallpy, liderando a área de Agilidade no Centro de Excelência, onde define a visão estratégica, governa modelos operacionais, otimiza fluxos de valor e estabelece métricas de desempenho e previsibilidade. Reconhecido como referência técnica e cultural, atua como mentor e coach de líderes, Agile Masters e Scrum Masters, apoiando transformações em larga escala, desenvolvimento de maturidade organizacional e a consolidação de uma cultura de melhoria contínua, colaboração sistêmica e foco em resultados de negócio.
Senior Principal Agile Leader na Zallpy, com sólida experiência na definição e evolução de modelos ágeis escaláveis, sustentáveis e orientados à geração de valor. Atualmente atua como Senior Principal Agile Leader na Zallpy, liderando a área de Agilidade no Centro de Excelência, onde define a visão estratégica, governa modelos operacionais, otimiza fluxos de valor e estabelece métricas de desempenho e previsibilidade. Reconhecido como referência técnica e cultural, atua como mentor e coach de líderes, Agile Masters e Scrum Masters, apoiando transformações em larga escala, desenvolvimento de maturidade organizacional e a consolidação de uma cultura de melhoria contínua, colaboração sistêmica e foco em resultados de negócio.
Autor verificado
Autor verificado
Autor verificado