Eu já tive 17 desenvolvedores simultâneos e rodei a cartilha do Scrum aqui dentro. Cortei o Scrum Master, engoli o planning poker, encurtei a sprint de mensal pra quinzenal e da quinzenal pra semanal. Hoje eu não tenho sprint fechada — e não é porque eu virei relaxado. É porque a conta mudou: o que a equipe estimava em 3 dias sai em 3 horas, e eu ainda não achei uma métrica justa pros dois lados.
Resposta rápida: como eu coordeno meu time de dev hoje, em setembro de 2026 — (1) sem sprint fechada, backlog contínuo e prioridade definida com suporte e comercial; (2) a daily virou orientação, e é nela que a semana se define, principalmente na de segunda; (3) story point e planning poker saíram, porque a nota de dificuldade media o esforço de um humano escrevendo código e não é mais o humano que escreve; (4) a conta que eu uso: o que a IA estima em 3 dias de humano, ela faz em 3 horas — mas a inversa não vale, tarefa de 30 dias não cabe em 5; (5) o desenvolvedor é dono do produto inteiro, não de uma camada, e precisa entender arquitetura e como aquilo gera dinheiro na ponta; (6) o gargalo novo não é escrever, é revisar código de terceiro, que esgota muito mais; (7) eu quero voltar pra sprint — falta a métrica justa, e commit, linha de código e token consumido não são ela.
Gravei quase 16 minutos sobre isso em 13/09/2026 no canal @josimarjmv, sem edição, nessa câmera e nessa câmera. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito, com mais calma e com o que eu fui conferir depois na fonte.
🎧 PREFERE OUVIR? · 16 min
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Vou dar minha carteirada logo no começo: eu tenho uma empresa de tecnologia e boto a mão na massa. Além de coordenar infraestrutura, suporte e vendas, eu coordeno manualmente a equipe de desenvolvimento e a de infra.
Ao longo dos anos passaram vários métodos de gestão aqui dentro. A gente chegou a ter 17 desenvolvedores simultâneos na equipe, e quase 400 pessoas já trabalharam com a gente nesse período. Escritório em São Paulo, escritório em Campinas, time de marketing, de suporte, de vendas. Então quando eu falo de Scrum, de story point e de sprint, não é papagaio digital repetindo o que leu: é o que eu implementei, o que eu paguei e o que eu cortei.
E é isso que este texto é: o método que está funcionando aqui hoje, com o que ainda está torto dito na cara.
A gente seguia a cartilhazinha do Scrum, chegou a implementar direitinho. Aí a galera veio com o Scrum Master. Durou pouquíssimo tempo e eu cortei.
Desculpa os caras que fazem isso, mas pra mim foi o cargo mais inútil que teve aqui. O sujeito não é tech, não é desenvolvedor, não é planejador, e depende de todo mundo pra fazer qualquer coisa. Não agregou qualidade, não agregou melhoria. Pelo contrário: tirou tempo da equipe de desenvolvimento, porque ele gastava muito tempo pra entender o projeto — não era tech leader, não sabia o que podia e o que não podia ser feito, e pra descobrir isso ele ocupava a cabeça de quem estava desenvolvendo.
Conferido por mim em 14/09/2026: o Scrum Guide de 2020 diz que "o Scrum Master é responsável por estabelecer o Scrum como definido no Scrum Guide" e que faz isso "ajudando todos a entender a teoria e a prática do Scrum". Leia com atenção o que essa definição entrega de resultado técnico: nada. O papel existe pra manter o método de pé. Numa empresa pequena e de médio porte, onde eu já conheço o sistema e ponho a mão nele, eu não tenho orçamento pra pagar alguém que cuida do método enquanto os outros cuidam do produto.
Dentro do Scrum você tira uma coisa ou outra que usa. A daily eu uso até hoje — tanto que eu levei pro marketing, pro suporte e pro comercial. Naquela época eu tinha daily de marketing, daily de suporte, daily de vendas, todas derivadas da daily do time de desenvolvimento. E cheguei a ter uma daily separada da galera de infraestrutura, porque com o time de desenvolvimento junto já não estava dando muito certo.
Todo dia, todo dia, pra funcionar direitinho. A daily é essencial.
No papel, a daily do Scrum Guide é "um evento de 15 minutos para os Desenvolvedores", cujo propósito é "inspecionar o progresso em direção à Meta da Sprint e adaptar o Sprint Backlog conforme necessário". Aqui em casa ela passou a fazer mais do que isso: virou o lugar onde o trabalho se define, e eu explico logo abaixo por que foi parar nesse ponto.
Teve uma época que vieram com a besteira do planning poker, que é uma derivação do story point. Se você não conhece: a galera dá uma pontuação de dificuldade pra tarefa, faz-se uma média, e desse número sai o tempo de entrega da tarefa conforme o nível de dificuldade que a própria equipe colocou.
Eu olhava aquilo e não via produtividade nenhuma. Squad pequeno, cinco, seis pessoas, os caras tudo amigo. Se fosse cada um de um lado do mundo, talvez desse mais certo. Aqui, a galera se protegia muito. E sempre tinha um — a gente tinha o problema do chinelinho, que montava no resto da equipe. Já tive chinelinho aqui também, não vou mentir. Eu cobrava o gerente do setor na época, e a cobrança era complicadíssima, protegida por todo lado. No fim teve que trocar o gerente também.
Mesmo com sênior, pleno e júnior na equipe, esse negócio do ponto nunca me deu régua nenhuma. E, sinceramente, ele ficou bastante tempo — coisa que eu nunca gostei, sendo honesto contigo, mas que muita empresa ainda usa como base.
Uma coisa que quase ninguém sabe e vale a conferida: o Scrum Guide de 2020 não manda usar story point. Não tem ponto, não tem Fibonacci, não tem baralho. O que está escrito é que "os Desenvolvedores que farão o trabalho são responsáveis pelo dimensionamento". Ou seja, a cartilha do ponto é adaptação de mercado, e virou dogma por repetição. Se você está apanhando pra defender o seu story point, saiba que você não está defendendo o Scrum. Está defendendo um hábito.
E agora tem o argumento que encerra o assunto pra mim: a nota de dificuldade media o esforço de um humano escrevendo aquele código. Não é mais o humano que escreve a maior parte. A régua mede uma coisa que saiu de cena.
Se você pedir pra IA estimar o tempo de uma tarefa, ela vai estimar o tempo de um humano fazer. É assim que ela foi treinada a responder. Então a conta que eu tenho é mais ou menos a seguinte:
A régua que eu uso: se ela estimou três dias, são três horas que ela gasta pra fazer, no máximo — testando, fazendo ponta a ponta. Mas a conta inversa não vale. Eu não posso pegar uma tarefa de 20, 30 dias, botar em 5 e cobrar o desenvolvedor que entregue naquele tempo. Não é realidade, principalmente se ele não tem conhecimento de infraestrutura e de arquitetura, ou se é a primeira vez que ele pega aquele projeto.
E tem um caso em que a conta inverte de vez: projeto legado. Muitas vezes o desenvolvedor desembola mais sozinho do que com IA, a não ser que seja pra transferir conhecimento. Falta documentação, não tem docstring, ninguém sabe por que aquilo foi feito daquele jeito — e a máquina, que aprende lendo, chega ali tão cega quanto o humano novo. Complica bastante.
Do outro lado da régua está o caso fácil, e ele é impressionante: eu passo uma feature de manhã, dentro de um projeto já estruturado, e à tarde essa feature pode estar pronta. Uma feature que na mão você gastaria três, quatro dias. O que ficou caro foi o começo: o start do produto é o mais difícil — padronizar, cuidar de segurança, montar teste, botar os guard rails pra segurar a mão da IA. Essa parte demora bem mais. Depois que a casa está de pé, a feature voa.
Essa diferença entre "start" e "feature" é a mesma coisa que eu já contei aqui quando falei do erro de arquitetura que mata o SaaS de quem cria software com IA: o dinheiro e o risco estão na fundação, não na parede.
No comecinho a galera queria fazer sprint mensal e puxava o backlog do mês. Eu vi que não dava, a galera se perdia. Encurtei pra quinzenal. Depois de um tempo a quinzenal também se perdeu, e aí já estava entrando o negócio da inteligência artificial. Chegamos na sprint semanal.
E hoje eu não tenho nem essa. Eu e minha equipe de dev estamos definindo as coisas na daily, porque não está dando pra definir de outro jeito. Eu conheço o sistema, eu sei como se faz. Mesmo se eu fosse ficar por conta de planejar, eu gastaria o meu tempo inteiro planejando pra uma IA fazer — e aí eu não preciso do desenvolvedor, sendo muito honesto contigo.
O desenho de hoje é este:
Sobre esse último ponto, duas exceções que eu faço questão de dizer, porque generalizar aqui seria mentira: infraestrutura ainda não dá pra diluir dessa forma, e o pessoal de mobile é mais difícil de trazer pro full stack — muitos não têm noção nenhuma de back end. Alguns têm, obviamente; não são todos. Mas é mais difícil transformar o cara de mobile em super stack do que trazer quem já vive entre o banco e a API.
Se a escrita do código deixou de ser o gargalo, o que sobra de valor no desenvolvedor é exatamente o que a máquina não tem: contexto de negócio.
Ele precisa entender a arquitetura e precisa entender como o produto funciona pra gerar valor lá na ponta. Tem que gerar dinheiro no usuário. É isso. Eu preciso que ele entenda o fluxo completo do produto em que está trabalhando — não o pedaço dele, o fluxo todo. Quem só enxerga o próprio componente não consegue nem julgar se o que a IA devolveu está certo pro negócio.
É a mesma conversa que eu tive aqui quando escrevi sobre o que eu faria pra não ser cortado numa onda de demissão: quem sabe fazer feature disputa com a máquina; quem entende o produto inteiro manda nela.
Aqui está a parte que quase ninguém mede quando fala de produtividade com IA. O esgotamento mental que a gente tem hoje é outro: arquitetar, conferir código de IA, fazer teste — esse loop, o dia inteiro.
É esgotante ficar lendo código de terceiro. No nível mental é muito mais fácil você ler o seu próprio código: você sabe o que fez, já está na sua cabeça. Ler e debugar código dos outros — que é o que a gente faz o tempo todo agora — gasta muito mais energia. E não é só "ler". É conferir se foram atendidos todos os requisitos, se o requisito de segurança está lá, se foi usado o padrão da casa, se ele não inventou uma migration que mete outra tabela pra guardar a mesma informação que você já tem no banco.
Isso acontece demais se você deixar solto e livre. Se você faz só vibe code, sem entender de arquitetura e sem padronizar, pode ir olhar agora: você vai achar tabela que faz a mesma função no seu banco. Cinco tabelas com a mesma informação. Se o banco for grande, certeza absoluta.
Conferido por mim em 14/09/2026, porque eu não quero que você acredite só em mim: a METR publicou um estudo controlado com 16 desenvolvedores experientes em repositórios grandes de código aberto (média de mais de 22 mil estrelas e mais de 1 milhão de linhas), sorteando 246 tarefas com e sem ferramenta de IA. Resultado: com IA eles levaram 19% mais tempo — e, mesmo depois de terem sido mais lentos, ainda achavam que a IA tinha acelerado o trabalho deles em 20%. É uma fotografia do início de 2025, num cenário específico de código maduro e desenvolvedor que já conhece o projeto de cor. Não é a minha realidade em projeto novo, onde a aceleração é escandalosa. Mas casa perfeitamente com o que eu sinto no legado e com a sensação de esgotamento: a percepção de velocidade e a velocidade real se descolaram. Por isso eu desconfio de métrica baseada em sensação — inclusive da minha.
Uma coisa que mudou o dia a dia aqui: a parte agêntica que entrega sozinha já fala com a minha equipe da ponta do suporte.
O fluxo é esse: o suporte cria a issue de bug; a parte agêntica valida, organiza e pergunta — se tiver dúvida de regra de negócio, ela me manda; eu interfiro, digo qual é a regra, e aí ela desenvolve e coloca pra gente testar. Passou nos testes, vai pro QA testar de novo.
Tarefa mais simples — alteração de banco, correção de bug — é o que sai mais fácil, porque é pouca coisa pra validar. O difícil é arquitetura. Bug é a coisa mais fácil que tem hoje, e eu vou além: hoje eu tenho um prazer enorme em debugar, porque a IA me ajuda a ler log numa velocidade absurda.
Antes, se aparecia um bug pro qual eu não tinha previsto alerta, eu tinha que sair caçando nas minhas dashboards, nos Grafana da vida. Hoje isso vem numa velocidade absurda. Debugar hoje é a coisa mais linda que tem no mundo — só que tem um pré-requisito que ninguém escapa: tem que ter log. Eu escrevi um texto inteiro sobre isso, com o caso dos 30 GB de log que eu tive que ler pra achar um problema no CDN. Sem observabilidade, essa parte agêntica toda vira chute automatizado.
Eu vi uns caras falando coisa sem nenhum cabimento: medir quantidade de commit. Depois quantidade de linha de código. E agora a bola da vez, quantidade de token consumido. Nada a ver, absolutamente nada a ver. Isso mede movimento, não mede valor — e qualquer uma delas é trivial de inflar quem quiser inflar.
A métrica que vale é a de qualidade, e ela bate lá na ponta: o cliente está satisfeito com o software, com o sistema, com o que foi implementado? A gente tem toda a telemetria aqui pra acompanhar isso. O problema é o atraso: você subiu pra pré-produção, testou, a feature foi desenvolvida há uma ou duas semanas — e a resposta só volta depois. Aí eu teria que voltar no tempo pra fechar a conta daquela semana. Entende o buraco? O ciclo da entrega ficou mais rápido que o ciclo da avaliação.
Conferido por mim em 14/09/2026: o relatório DORA de 2025 sobre desenvolvimento assistido por IA, com quase 5 mil profissionais de tecnologia, achou 90% de adoção de IA no trabalho e mais de 80% dizendo que ela aumentou a produtividade — mas também 30% com pouca ou nenhuma confiança no código que a IA gera. E o achado que eu grifei: nesse ano a adoção de IA aparece com relação positiva com o throughput de entrega e, ao mesmo tempo, relação negativa com a estabilidade da entrega. A conclusão deles é a mesma que eu vivo aqui: a IA é um amplificador, e "sem sistemas de controle robustos — teste automatizado forte, práticas maduras de versionamento e ciclos rápidos de feedback — o aumento no volume de mudanças leva à instabilidade". Você acelera a produção e descobre que o gargalo mudou de lugar.
Deixa eu ser claro: eu quero voltar a fazer sprints. Eu acho legal. E eu não tenho absolutamente nada contra ter um serviço que gerou valor pra mim na semana, o cara trabalhar três dias feito doido, entregar e ficar livre os outros dois. Problema nenhum. O que falta é a métrica que torne isso justo dos dois lados.
Porque a régua tem que servir pros dois: eu sou uma empresa de médio porte, meu dinheiro é pequeno. Eu não posso me dar ao luxo de usar o cérebro que eu estou pagando por três, quatro horas na semana. Tenho que usar um pouco mais. Mas também não posso sugar mentalmente o cara até quebrar — ainda mais agora, que o trabalho dele virou revisar código de terceiro o dia inteiro. Tem que ser justo dos dois lados. Enquanto eu não acho essa régua, eu prefiro assumir o backlog contínuo do que fingir que a sprint está medindo alguma coisa.
E olha que o chão está se mexendo debaixo do pé enquanto eu procuro. Veio o Fable aí e é uma doideira: segue padrão, não avacalha as coisas, faz certinho o que foi pedido — desde que você mantenha contexto e abra sessões limpas pra desenvolver. A cada modelo novo a minha régua de estimativa envelhece. É por isso que eu não cravo uma fórmula neste texto: qualquer número que eu fechasse hoje estaria velho no mês que vem.
O time está desembolando bem e entregando muito mais coisa do que antes. Existem melhorias pra fazer, ainda não está do jeito que precisa. Mas prefiro contar assim, torto e honesto, do que vender método fechado.
E aí, como está na sua empresa? Eu quero mesmo ouvir isso: se tem AI first aí e a galera usa de fato, se existe preocupação com produtividade, que régua vocês estão usando. Comenta lá no vídeo do canal pra gente compor alguma coisa junto — eu estou atrás de um método justo pra mim, que pago a conta, e pra você, que desenvolve.
Quer montar isso do seu lado? Se o seu plano é ter o seu próprio produto rodando com uma equipe enxuta, a Imersão de SaaS pega o produto do banco ao monitoramento. Se o gargalo é a base onde tudo roda, é a Imersão de Infraestrutura. Tem também a Imersão de Sites e a de chatbot. Data, preço, formato e condição de cada uma estão em todas as imersões — é a página que vale, nunca o que eu falei num vídeo.
Nota de cronologia. Esse relato é da gravação que eu publiquei em 13/09/2026, e é assim que a minha operação está funcionando neste momento — backlog contínuo, sem sprint fechada. É um modelo em transição, não é dogma: se eu achar a régua que eu estou procurando, eu volto pras sprints semanais e conto aqui. Os números de equipe (17 desenvolvedores simultâneos, quase 400 pessoas ao longo dos anos) são histórico da empresa, não o tamanho do time hoje.
TODA SEGUNDA · MEIO-DIA · AO VIVO
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Baseado na gravação do canal @josimarjmv publicada em 13/09/2026 (15min52), com transcrição própria das legendas do próprio vídeo. Os 17 desenvolvedores simultâneos, as quase 400 pessoas que já passaram pela empresa, os escritórios de São Paulo e Campinas, o corte do Scrum Master, o caso do gerente trocado, a evolução das sprints até o backlog contínuo, a régua de três dias virando três horas, o fluxo agêntico com a equipe de suporte e a busca por uma métrica justa são da minha vivência tocando a JMV Technology. Conferido por mim em 14/09/2026: as definições de Scrum Master, Daily Scrum, duração da Sprint e responsabilidade pelo dimensionamento no Scrum Guide de 2020, que não prescreve story point; o resultado de 19% mais tempo com ferramentas de IA no estudo controlado da METR com 16 desenvolvedores experientes e 246 tarefas; e os números de adoção, confiança, throughput e estabilidade do relatório DORA de 2025. Nenhuma dessas organizações tem relação comercial comigo. Data, preço, vaga e condição de cada imersão são os que estão em todas as imersões.