O que são story points? Guia prático

Um story point (ponto de história) é uma unidade de esforço relativo que o time atribui a um trabalho, combinando o quão complexo ele é, o quão incerto ele é e o quanto há dele, em vez de quantas horas vai levar. O time compara cada item com os outros ("isto é mais ou menos o dobro daquele") em vez de prever um tempo de relógio. Os pontos costumam ser escolhidos com uma escala como Fibonacci durante uma sessão de planning poker. Abaixo: o que eles realmente medem, o que a evidência diz, e como usá-los sem prometer demais.

O que é um story point?

Um story point responde a uma pergunta comparativa, não absoluta. Em vez de "quantas horas isto vai levar", o time pergunta "qual o tamanho disto comparado a trabalhos que já conhecemos". Uma história que todos concordam ser pequena pode ser um 2, algo mais robusto um 5, algo grande e nebuloso um 13. O número não tem um tempo fixo atrelado. É um tamanho relativo e compartilhado.

A ideia de usar uma unidade abstrata é separar a estimativa da velocidade de qualquer pessoa específica e da pressão de se comprometer com um prazo. Um dev júnior e um sênior podem levar tempos diferentes, mas em geral conseguem concordar que um item é mais ou menos o dobro de outro.

Do que um story point é feito

Três coisas entram em um único número:

• Complexidade: o quão intrincado é o trabalho, quantas partes móveis, quantos sistemas ele toca.
• Incerteza: o quanto o time ainda não sabe. Desconhecidos e risco empurram o número para cima.
• Volume: o quanto há de trabalho repetitivo, mesmo quando cada pedaço é simples.

É por isso que dois itens que levariam horas parecidas podem receber pontos diferentes. Uma mudança simples espalhada por quarenta arquivos e um algoritmo difícil em um único arquivo são ambos "grandes", por motivos distintos.

Por que times estimam em pontos em vez de horas

A estimativa relativa é popular por razões que têm mais a ver com pessoas do que com matemática:

• Desacopla a estimativa do indivíduo. Horas dependem de quem faz o trabalho. O tamanho relativo tende a ser mais estável entre pessoas.
• Comparar é mais rápido do que prever. Julgar que um item é maior que outro é mais rápido do que prever uma duração exata, então as sessões andam mais rápido.
• Resiste à falsa precisão. "13 pontos" sinaliza a incerteza com honestidade. "16,5 horas" finge uma precisão que ninguém tem.
• Conduz a conversa. O verdadeiro resultado de estimar em grupo não é o número. É a discussão que traz à tona o trabalho escondido, como em uma sessão de planning poker.

Esses são benefícios reais. Mas vale ser honesto sobre a parte que a maioria dos guias pula.

O que a pesquisa realmente diz

A afirmação comum de que story points são mais precisos do que estimativas em horas não é bem sustentada por estudos controlados.

Em um conjunto de experimentos controlados, desenvolvedores profissionais estimaram as mesmas tarefas de dois jeitos: uns davam story points, outros davam horas. As estimativas em story points saíram menos precisas do que as em horas, e levaram mais tempo para serem feitas, mesmo entre devs com bastante experiência em story points. O mesmo trabalho achou que o "tamanho" em pontos de uma tarefa mudava bastante dependendo de quem estimava, o oposto da propriedade de ser independente da pessoa que os pontos deveriam ter.

O padrão se mantém em larga escala. Em uma análise de 2022 com 37.440 histórias reais em 37 projetos open-source, pesquisadores compararam os story points de cada time com quanto tempo o trabalho de fato levou. Os pontos bateram bem com o esforço real em apenas cerca de 7% dos projetos. No resto, a relação foi média ou fraca, e a estimativa humana original ficou errada, alta ou baixa demais, em cerca de três de cada quatro histórias. Revisões mais amplas de estimativa ágil chegam a uma versão mais branda da mesma conclusão: story points são a forma mais comum de os times dimensionarem o trabalho, mas não há evidência sólida de que preveem o esforço com precisão. (Referências completas em Fontes, abaixo.)

A conclusão honesta: story points não são uma forma confiável de prever quanto tempo um único item vai levar. Se você os adota esperando previsões precisas por item, vai se decepcionar, e a pesquisa explica por quê.

Então para que servem os story points?

Para bastante coisa, desde que você os use para o trabalho certo.

• Entendimento compartilhado. Quando os votos divergem, a discussão revela premissas, tarefas esquecidas e risco. Esse alinhamento é a verdadeira entrega, e é por isso que a técnica vale o tempo.
• Previsão aproximada ao longo de muitos itens. Estimativas individuais são ruidosas, mas em um backlog inteiro os erros se cancelam em parte. Acompanhar quantos pontos o time conclui por sprint (sua velocidade) dá uma previsão útil e aproximada, muito melhor do que somar horas chutadas.
• Sinalizar os itens assustadores. Um 13 ou um 21 é um sinal: isto está grande ou desconhecido demais. Quebre antes que doa.
• Manter a estimativa humana. O dimensionamento relativo evita a pressão de prazo e a culpa individual que as estimativas em horas provocam.

Note que nada disso exige que os pontos sejam iguais ao esforço com precisão. Exige um time que conversa e compara de forma consistente.

Como estimar em story points

1. Escolha uma escala. A maioria dos times usa um deck Fibonacci (0, 1, 2, 3, 5, 8, 13, 21). Os intervalos crescentes espelham a incerteza crescente, então você não precisa discutir detalhes entre itens grandes.
2. Escolha uma história de referência. Combinem um item bem compreendido como âncora ("este é o nosso 3"). Estimem todo o resto comparando com ele.
3. Estimem juntos, revelem juntos. Usem planning poker para ninguém se ancorar no primeiro número falado. O método completo está no nosso guia passo a passo.
4. Reestimem quando souberem mais. Pontos são um retrato do entendimento atual, não um contrato. Atualizem quando o quadro mudar.

Story points vs. horas

Nenhum dos dois é mágico. Se um stakeholder realmente precisa de uma data, pontos sozinhos não vão dar. A tendência da velocidade mais uma conversa chega mais perto do que uma pilha de horas chutadas.

Erros e usos indevidos comuns

• Converter pontos em horas. Uma tabela "1 ponto = 4 horas" joga fora toda a razão de usar pontos e reintroduz a falsa precisão.
• Comparar velocidade entre times. Pontos são calibrados por time. O 8 do time A não é o 8 do time B. Usar velocidade como ranking de produtividade é um anti-padrão conhecido.
• Tratar pontos como métrica de desempenho. No momento em que os pontos viram meta, eles inflacionam e param de significar algo (a lei de Goodhart na prática).
• Esperar precisão item a item. Como a pesquisa mostra, os pontos de um único item são um previsor fraco do tempo real. Faça a previsão ao longo de muitos itens, não de um.
• Nunca reestimar. Pontos definidos antes de o trabalho ser compreendido não são sagrados. Atualize-os.

Perguntas frequentes

Story points são o mesmo que horas?

Não. Horas são uma duração absoluta atrelada a uma pessoa específica. Story points são um tamanho relativo que combina complexidade, incerteza e volume, e devem ser independentes de quem faz o trabalho.

Quantas horas é um story point?

Não existe conversão fixa, e criar uma anula o propósito. Alguns times observam de forma solta que um ponto costuma levar uma certa faixa de tempo para eles, mas isso é um padrão percebido depois, não uma regra para estimar.

Qual escala usar para story points?

Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) é a mais comum, porque os intervalos crescentes refletem a incerteza maior em itens grandes. Tamanhos de camiseta servem para um dimensionamento rápido e grosseiro.

Story points são realmente precisos?

Para prever o esforço de um único item, a evidência é fraca: estudos controlados não mostraram vantagem clara de precisão sobre horas, e uma análise em larga escala achou que os pontos se correlacionam com o esforço real de forma inconsistente. O valor deles está no entendimento compartilhado e na previsão aproximada ao longo de muitos itens, não na previsão precisa item a item.

Dá para comparar velocidade entre times?

Não. Pontos são calibrados dentro de um time, então a velocidade de um time não é comparável à de outro. Usar velocidade para ranquear times incentiva a inflação de pontos e é um anti-padrão comum.

Quem atribui os story points?

As pessoas que vão fazer o trabalho, juntas, normalmente em uma sessão de planning poker. O Product Owner esclarece o escopo mas não define o número, e o Scrum Master facilita.

Story points medem esforço ou complexidade?

Ambos, mais incerteza e volume. Eles juntam vários fatores em um único número relativo, e é por isso que dois itens com esforço bruto parecido podem receber pontos diferentes.

Fontes

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates? (experimentos controlados com desenvolvedores profissionais).
3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022 (37.440 histórias, 37 projetos).
4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.