Story Points Não São Estimativas de Tempo (E Por Que Isso Importa)
A cada poucos meses, a mesma cena acontece. Um product manager entra numa reunião de planeamento, a equipa atribui story points a um conjunto de tickets, e depois alguém tira uma folha de cálculo a converter esses pontos em horas para poderem prometer uma data de entrega às partes interessadas.
E assim, o propósito inteiro dos story points desmorona.
Já vi isto acontecer em startups, em scale-ups, e em empresas que deviam saber melhor. A causa raiz é sempre a mesma: um equívoco fundamental sobre o que os story points devem medir — e uma cultura de gestão que não consegue resistir a traduzir tudo numa linha do tempo.
O Que os Story Points Realmente Medem
Os story points são uma unidade de complexidade relativa. Comparam o esforço de um trabalho com outro, tendo em conta complexidade, incerteza e risco — não horas de relógio.
Quando uma equipa diz "este é um 5 e aquele é um 2", está a dizer que a primeira tarefa é aproximadamente 2,5 vezes mais complexa do que a segunda. Não está a dizer que a primeira tarefa demora 5 horas ou 5 dias. O número é relacional, não absoluto.
Esta distinção importa porque:
- Dois programadores podem completar a mesma história de 5 pontos em quantidades de tempo muito diferentes. Um conhece melhor a base de código. O outro é mais rápido a fazer debugging. A complexidade do problema é a mesma para ambos.
- Uma história de 5 pontos neste sprint pode demorar mais do que uma história de 5 pontos no último sprint. Mudanças de contexto, incidentes em produção, mudanças na equipa — tudo isto afeta a duração mas não a complexidade.
- A complexidade é estimável; a duração não é. Os engenheiros são razoavelmente bons a comparar a dificuldade de duas tarefas. São péssimos a prever quantas horas algo vai demorar. Os story points aproveitam o ponto forte e evitam o ponto fraco.
No momento em que começas a dizer "1 ponto = meio dia", abandonaste a estimativa relativa e estás de volta às estimativas de tempo com passos extra.
Por Que os Gestores Convertem Pontos em Tempo (E os Danos que Causa)
Percebo. Se és um product manager ou um CEO, precisas de responder "quando é que isto vai estar pronto?" É uma questão legítima. O problema é o atalho: pegar nos story points e dividir por uma "velocidade" para produzir uma data.
Eis o que realmente acontece quando fazes isto:
As equipas começam a manipular os números. Se a gestão trata os pontos como tempo, os engenheiros aprendem a inflar estimativas para não serem pressionados por "comprometer-se" com demasiados pontos. O que era um 3 torna-se um 5. O que era um 5 torna-se um 8. Os números deixam de significar alguma coisa.
A velocidade torna-se uma métrica de desempenho. Em vez de ser uma ferramenta de planeamento, a velocidade transforma-se num marcador. As equipas que "entregam" mais pontos são recompensadas. As equipas começam a dividir histórias artificialmente ou a inflar estimativas para parecerem mais produtivas. Estás agora a medir a coisa errada e a incentivar o comportamento errado.
A confiança erode. Os engenheiros sentem-se vigiados em vez de confiáveis. Passam mais energia a gerir expectativas do que a resolver problemas. O sprint planning deixa de ser uma conversa colaborativa sobre o que é realista e torna-se uma negociação onde ambos os lados estão a posicionar-se.
A precisão das estimativas piora, não melhora. A ironia é cruel: quanto mais pressão aplicas para estimativas de tempo precisas, menos fiáveis se tornam as tuas estimativas. A pressão introduz viés. O viés destrói o sinal.
Alternativas que Realmente Funcionam
Se os story points estão a ser mal utilizados na tua equipa, tens opções. Algumas equipas funcionam melhor mudando para uma abordagem diferente completamente.
Dimensionamento em T-shirt
Em vez de números, usa S/M/L/XL. É deliberadamente impreciso, o que é o ponto. Força conversas sobre tamanho relativo sem a ilusão de precisão matemática. Um product owner pode olhar para um roadmap de mediums e larges e ter uma noção aproximada do âmbito sem que ninguém finja que um L tem exatamente 3,5 dias.
O Movimento Sem Estimativas
Este é mais radical: para completamente de estimar histórias individuais. Em vez disso, foca-te em dividir o trabalho em peças pequenas e de tamanho semelhante e mede o débito. Se a tua equipa completa uma média de 12 itens por sprint e o backlog tem 36 itens de tamanho semelhante, podes prever "cerca de 3 sprints" sem nunca atribuir um número a qualquer história individual.
Isto funciona melhor quando tens disciplina na decomposição de histórias. Se algumas histórias são minúsculas e outras são enormes, as previsões baseadas em débito desmoronam.
Previsão por Tempo de Ciclo
Esta é a minha abordagem preferida para equipas que têm pelo menos alguns meses de dados históricos. Em vez de estimar para o futuro, olhas para o passado sobre quanto tempo o trabalho realmente demora.
O tempo de ciclo é a duração desde quando o trabalho começa até quando está feito. Se rastreares isto por história ou por ticket, podes calcular percentis:
- "85% das nossas histórias ficam prontas dentro de 7 dias."
- "50% ficam prontas dentro de 3 dias."
Agora quando alguém pergunta "quando é que isto vai estar pronto?" dás uma resposta probabilística: "Com base no nosso histórico, há uma probabilidade de 85% de estar pronto dentro de 7 dias úteis." Isso é mais honesto, mais defensável e mais útil do que qualquer estimativa baseada em pontos.
Ferramentas como Jira, Linear e Shortcut podem gerar dados de tempo de ciclo. Não precisas de nada sofisticado — uma folha de cálculo a rastrear a data de início e a data de conclusão por história dar-te-á 80% do valor.
Quando a Estimativa Acrescenta Valor
Não sou contra a estimativa. A estimativa é útil quando serve um propósito claro:
- Delimitar grandes iniciativas. Quando precisas de decidir entre dois projetos que podem demorar 3 meses vs. 9 meses, a estimativa aproximada ajuda a alocar recursos e a definir expectativas. O dimensionamento em T-shirt ou o story mapping funciona bem aqui.
- Identificar incógnitas. Se a equipa não consegue concordar se algo é um 3 ou um 13, esse desacordo é o valor. Surfaça diferentes assunções, requisitos em falta e complexidade oculta. A conversa em torno da estimativa é mais valiosa do que o número.
- Planeamento de capacidade. Saber aproximadamente quanto trabalho cabe num sprint ajuda as equipas a evitar comprometer-se excessivamente. Mas isto só funciona se protegeres as estimativas de serem transformadas em armas em prazos.
Quando a Estimativa É Puro Desperdício
A estimativa acrescenta zero valor quando:
- Cada história é aproximadamente do mesmo tamanho. Se a tua equipa ficou boa a dividir o trabalho em pedaços pequenos, as estimativas são redundantes. Basta contar histórias.
- As estimativas não alimentam nenhuma decisão. Se ninguém usa as estimativas para tomar uma decisão de planeamento, estás a gastar 30 minutos por sprint num ritual que não produz nada.
- As estimativas são usadas para culpar, não para planear. "Disseste que isto era um 3 e demorou uma semana." Se essa frase já foi pronunciada na tua equipa, o teu processo de estimativa está a fazer mais mal do que bem.
O Objetivo Real: Previsibilidade, Não Precisão
Eis o que a maioria das pessoas não percebe: o objetivo de qualquer prática de estimativa é a previsibilidade, não a precisão. Não precisas de saber que a Funcionalidade X vai demorar exatamente 14 dias. Precisas de saber que a tua equipa consegue entregar de forma fiável um conjunto de funcionalidades num trimestre. Esse é um problema diferente, e é resolvido com métricas de fluxo, não com melhores adivinhações.
Rastreia o tempo de ciclo. Mede o débito. Monitoriza os limites de trabalho em progresso. Estes são indicadores retardados que refletem a realidade, não indicadores antecipados que refletem esperança.
As equipas com as quais trabalhei que têm a maior previsibilidade de entrega não são as que têm os rituais de estimativa mais sofisticados. São as que mantêm o trabalho pequeno, limitam o WIP e usam dados históricos para prever. Não é necessário planning poker.
Na Conectia, os engenheiros sénior que integramos nas tuas equipas compreendem isto. Já trabalharam em equipas suficientes para saber que o teatro de estimativas desperdiça o tempo de todos, e trazem hábitos práticos — PRs pequenos, âmbito claro, débito consistente — que tornam a tua entrega previsível sem transformar o sprint planning numa negociação. É isso que engenheiros experientes fazem: fazem o processo funcionar, não apenas o código.
Cansado do teatro de estimativas a atrasar a tua equipa? Fala com um CTO — os nossos engenheiros sénior LATAM trazem os hábitos de entrega que tornam a previsibilidade um subproduto, não uma batalha.
