Ep. 107 - Você ainda usa story points?

Panda abre o episódio contando o que o motivou a propor o tema: ao rever um episódio anterior do Love the Problem em que a galera tocou de leve no assunto story points, ele lembrou de quanto já pesquisou, comparou dados de times reais e viu a prática sendo usada 'de uma maneira bem errada' nas empresas. A pergunta que quer perseguir não é se story points são bons ou ruins, mas: dá para usar, quando usar, quando não usar, vale a pena mesmo? Ele conta como sua própria relação com estimativas mudou ao longo do tempo, de comparação com raças de cachorro, passando por planning poker, horas e complexity points, até esbarrar numa frase que o marcou: um tuíte de Ron Jeffries pedindo desculpas por, segundo ele, ter criado o story point sem querer. Panda reconta a origem: no XP, times abandonaram estimativas em horas (que nunca batiam, porque cada pessoa trabalha num ritmo diferente) e passaram a usar 'Ideal Days'. Como 'três dias ideais' confundia todo mundo, já que não eram três dias corridos, Jeffries sugeriu tirar a palavra 'dias' e chamar só de 'Points'. Dali nasceu, talvez sem querer, o story point. No mesmo relato, Jeffries lista as disfunções que o entristecem: pessoas comparando entregas entre times, medindo quantos pontos cada indivíduo entrega, usando a técnica para coisas que nunca foi pensada para fazer.

Com esse contexto, Panda recebe André Caribé, que já participou de outros episódios e trouxe o tema, e Jéssica Ferrari, em sua primeira aparição no programa. A pergunta que batiza o episódio é colocada de forma genuína, sem julgamento: você ainda usa story points? Como usa? Por que usa? Que problema você está tentando resolver com isso? Jéssica conta que já estimou de tudo: complexity points, quantidade de linhas de código, número de botões na tela, planning poker, ordem dada pelo PO, e que o que mudou sua relação com o tema foi parar de perguntar 'quanto vale isso' e passar a perguntar 'por que estou estimando'. Na maioria das vezes, alguém no fim da cadeia quer saber quando algo fica pronto.

A discussão então mergulha na diferença entre esforço e tempo. Caribé defende que, na concepção original, story points medem esforço comparativo: a dificuldade técnica, a incerteza de uma tarefa em relação a outra, e que converter isso em tempo é embutir erro sobre erro: toda conversão de medida carrega sua própria margem de erro, e empilhar conversões (esforço → pontos → tempo) só aumenta a distância entre estimativa e realidade. Ele defende que, se o objetivo é dar uma data, seria mais simples medir tempo diretamente, ideia próxima da corrente 'no estimates', e cita um episódio anterior do próprio podcast sobre previsibilidade com Maíra e José Jr. Caribé compara o trabalho de conhecimento, criativo, não repetitivo, com o trabalho de fábrica, onde tudo é linear e previsível; no trabalho de conhecimento existem filas, dependências entre times e passagens de bastão que tornam qualquer conversão em tempo pouco confiável.

Jéssica pondera que o ser humano já é ruim para estimar tempo por natureza, cita o documentário 'Quanto Tempo Leva o Tempo?' e a subjetividade de algo tão simples quanto 'muito café', e que o story point, com sua sequência de Fibonacci, ao menos limita as opções disponíveis e força uma decisão. Ela descreve como usava a técnica na prática: sessões longas de planning poker ('sala de tortura'), cartas de 1 a 21, votos revelados ao mesmo tempo e busca por consenso quando havia divergência.

Panda assume a defesa do story point em contextos específicos. Primeiro, como forma de limitar quanto trabalho cabe dentro de uma sprint, uma estratégia de lote (batch) que se relaciona a tempo sem tentar prevê-lo com precisão. Segundo, e principalmente, pelo valor da conversa que a técnica pode gerar: quando duas pessoas votam 1 e 13 para o mesmo item, a divergência revela diferenças de entendimento que valem ouro para aprendizado e para fatiar o trabalho antes de assumir o compromisso. Caribé rebate: o que gera essa conversa rica é a técnica do planning poker, não o story point em si; a mesma discussão poderia acontecer com qualquer outra técnica de estimativa, e muitos times já usam story points sem nenhuma conversa, apenas jogando um número na tela, perdendo justamente o que haveria de valioso ali. Jéssica traz de volta o nome do próprio podcast: qual é o problema que estamos tentando resolver, dar uma estimativa de prazo ou resolver falta de engajamento e de troca de ideias no time? Alternativas sem número são mencionadas, como estimar por 'tamanho de bicho' (inspirado numa ilustração de kanban) ou por uma matriz de esforço versus complexidade, que também promovem a conversa sem depender de story points.

Panda então traz dados: ao rodar a correlação de Pearson entre story points estimados e tempo real de entrega em vários backlogs de times diferentes, o número nunca passou de 0,5, estatisticamente uma correlação fraca, insuficiente para afirmar que mais pontos significam mais tempo. Sobre o uso de story points para fatiar histórias grandes (por exemplo, um limite acordado de que itens acima de determinado valor precisam ser quebrados), o grupo reconhece que pode ser genuíno quando reflete incerteza real, mas também pode virar uma muleta emocional que tranquiliza o PO sem gerar entendimento de fato.

A conversa volta à pergunta “quando fica pronto”: para Jéssica, raramente a pessoa que pergunta quer mesmo a data exata; na maioria das vezes, é uma questão de gerenciar expectativa (de mercado, de cliente, de outra área). Além disso, estimar um pedacinho local do fluxo de um time isolado dificilmente representa a previsibilidade do todo. Panda alerta para a armadilha de o story point virar automatismo, campo obrigatório no Jira, item de relatório, sem propósito claro, e defende que toda prática ágil merece ser experimentada, avaliada e ajustada, não seguida por hábito.

Caribé recorda um tuíte de Troy Magennis comparando 'story points' (tamanho como esforço) e 'story count' (tamanho como quantidade/vazão): ambos têm forças e fraquezas dependendo de quão estreito, estável e independente é o sistema de trabalho: quanto menos dependências e mais domínio ponta a ponta o time tem, melhor o esforço tende a funcionar como preditor. Ele cita caminhos alternativos de previsibilidade baseados em fluxo: lead time, percentis e simulações Monte Carlo. Panda resume sua posição: para ele, story points valem mais como ferramenta de melhoria contínua e de aprendizado do que como instrumento de previsão de data, inclusive dentro do movimento #noestimates, que propõe olhar só para dados históricos de fluxo, mas cuja variabilidade alta também pode distorcer a previsão para cima. Jéssica compartilha que já defendeu o #noestimates publicamente, mas pondera: estimativa perde sentido quando vira só uma corrente de cobrança entre PO, PM, gerente e cliente; se o time já roda há um tempo, vale mais usar o lead time histórico do que insistir em estimar.

O grupo destaca, com humor, que ninguém ali defendeu comparar times por quantidade de story points entregues, e Panda pede, sério, que quem estiver fazendo isso na própria organização pare imediatamente. Segue-se uma lista rápida de antipadrões: não converter story points em horas por desenvolvedor para medir performance; não usar story points para pressionar entregas; não comparar times nem pessoas (júnior vs. sênior) por pontuação; não 'renormalizar' pontos quando uma história não termina na sprint e é carregada para a seguinte, o que esconde a variabilidade real do time; não usar story points como meta; não usar story points como indicador corporativo; não preencher story points só porque é campo obrigatório no Jira. Panda conta um caso real: um time de segurança global precisou estimar um grande volume de itens de correção; passadas semanas, ninguém lembrava das discussões feitas durante a estimativa e o time não entregou dentro do prazo que ele mesmo havia estimado, um desperdício de tempo evitável, já que prever um backlog inteiro via story points exige parar o time para estimar tudo de uma vez.

No fechamento, Jéssica deixa o recado de experimentar: casar story points com técnicas de previsibilidade, evitar usá-los para comparar pessoas, times e áreas, e nunca transformá-los em meta, porque isso muda o comportamento das pessoas para o lado errado: otimizar o número em vez de entregar valor. Caribé reforça que o cliente, e muitas vezes até pessoas dentro da própria empresa, não entende o que é um story point; por isso a sugestão é simplificar a comunicação, entender o que o stakeholder realmente valoriza e, se story points não forem a ferramenta certa para aquele público, buscar outra forma de promover a mesma conversa dentro do time. Panda fecha reforçando que, estimando ou não, o importante é manter a aprendizagem ativa no dia a dia dos times.