Story Points no desenvolvimento — o que são, escalas de avaliação e aplicação

O que são story points?

Story points são uma métrica de complexidade de tarefas usada no Scrum e em outras metodologias ágeis. A equipe avalia cada tarefa não em horas, mas em unidades relativas: “esta tarefa é duas vezes mais complexa que a referência.” Essa abordagem nivela a diferença de velocidade entre diferentes desenvolvedores e foca na complexidade.

Origem do termo

O conceito de story points surgiu no início dos anos 2000 com a popularização do Scrum. Um dos primeiros a descrever o método foi Ron Jeffries como parte da Extreme Programming (XP). A ideia era se afastar da estimativa em “horas-homem,” que é sempre imprecisa, em direção à complexidade relativa que a equipe determina coletivamente. Hoje, os story points são o padrão da indústria para equipes ágeis.

Fatores considerados nos story points

Ao estimar em story points, a equipe considera três fatores: volume de trabalho (quantidade de código, telas, lógica), complexidade (desafios técnicos, novas tecnologias) e incerteza (requisitos pouco claros, riscos). Um story point pode significar “uma tarefa simples sem riscos,” enquanto 8 pode significar “uma tarefa complexa com alta incerteza.”

Escalas de story points: como escolher

A escolha da escala de story points afeta a precisão da estimativa e a conveniência do planejamento. A escala mais popular é a sequência de Fibonacci, mas existem alternativas.

Por que Fibonacci? A psicologia da escala

A sequência de Fibonacci não foi escolhida por acaso. A diferença entre 1 e 2 é mínima (50%), enquanto entre 13 e 21 é significativa (62%). Isso reflete a realidade: tarefas pequenas são estimadas com mais precisão, tarefas grandes com maior dispersão. Quando uma tarefa é estimada em 21 story points, a equipe entende: “não sabemos quanto tempo vai levar, mas definitivamente é mais que 13.” A escala de Fibonacci evita a falsa precisão.

A tarefa de referência — base da escala

Para a escala funcionar, a equipe concorda com uma referência: “a tarefa X é 1 story point.” Geralmente, uma tarefa simples e bem conhecida é escolhida como referência: “adicionar um campo de texto a uma tela” ou “corrigir um bug de digitação.” Todas as outras tarefas são estimadas em relação à referência. Sem uma referência, os story points perdem o significado — cada pessoa entende a unidade de forma diferente.

Velocity da equipe e previsão

Velocity é o número médio de story points que uma equipe completa por sprint. Esta é uma métrica chave para prever os prazos do projeto.

Como o velocity é calculado

Velocity é calculado com base nas tarefas concluídas: soma-se os story points de todas as tarefas que a equipe conseguiu finalizar (definição de concluído foi atendida). Tarefas não concluídas não são contadas. Para precisão, calcula-se a média dos últimos 3–5 sprints. Por exemplo, se uma equipe completou 20, 22, 18 e 24 story points nos últimos 4 sprints, velocity = 21 sp.

Previsão através do velocity

Conhecendo o velocity e o volume total do backlog em story points, você pode prever o número de sprints até o lançamento. Por exemplo, se o backlog tem 210 story points e velocity = 21, serão necessários 10 sprints. Esta é uma previsão aproximada que é refinada conforme o trabalho avança. Importante: velocity é uma média, não um compromisso. Planeje com base no limite inferior (18 sp), não na média.

Como aumentar o velocity

Velocity não pode ser aumentado por decreto — é um sintoma da saúde dos processos. O crescimento sustentável do velocity é alcançado através de: redução da dívida técnica, melhoria dos processos de revisão de código, redução de mudanças de contexto, automação de testes e CI/CD. Importante: o velocity de diferentes equipes não pode ser comparado — cada equipe define story points à sua maneira.

Story points vs horas: o que e quando usar

Story points e horas têm propósitos diferentes, e a escolha entre eles depende do contexto. Equipes experientes usam ambas as abordagens para tarefas diferentes.

Quando story points funcionam melhor

Story points são indispensáveis para o planejamento de sprints: eles não dependem de quem vai fazer a tarefa. Um júnior pode fazer 2 sp por dia, um sênior 4 sp, mas a estimativa da tarefa permanece 2 sp para ambos. Story points permitem rastrear a produtividade da equipe sem comparar desenvolvedores. Isso reduz a pressão política e melhora o ambiente da equipe.

Quando as horas são necessárias

Horas são necessárias para compromissos externos: contratos, orçamentos, relatórios para o cliente. O cliente quer saber não “8 story points” mas “3 semanas.” Para converter story points em horas, use a taxa de conversão histórica: a equipe sabe que 1 sp equivale aproximadamente a 4 horas de trabalho. A conversão deve ser transparente e baseada em dados, não em suposições.

Abordagem combinada

Muitas equipes usam uma abordagem combinada: as tarefas são estimadas em story points para o planejamento do sprint, e então o gerente as converte em horas/dias para relatórios externos. É importante não misturar os dois sistemas em um único processo: ou você estima em story points e deriva o tempo do velocity, ou estima diretamente em horas.

Erros comuns ao trabalhar com story points

A implementação de story points é frequentemente acompanhada por erros que anulam os benefícios da estimativa relativa. Aqui estão os mais comuns.

Vincular story points ao tempo

O erro mais comum — a equipe concorda: “1 sp = 4 horas.” Nesse caso, os story points perdem seu significado e se transformam em horas com outro nome. Story points devem ser relativos, não vinculados ao tempo. Se a tarefa A é duas vezes mais complexa que a tarefa B, ela recebe 2 sp, independentemente de quantas horas levará.

Estimação post-factum

Quando uma tarefa é estimada após ser concluída — isso não é estimativa, é documentação. Story points devem ser atribuídos antes do início do trabalho, no momento de máxima incerteza. A estimativa post-factum distorce o velocity e não traz benefícios para o planejamento. Além disso, cria uma falsa sensação de precisão.

Comparar velocity entre equipes

Comparar o velocity da equipe A e da equipe B é um exercício sem sentido. Cada equipe define a referência e a escala de forma diferente. Para uma equipe, 1 sp é uma tarefa simples de uma hora, para outra é uma tarefa de um dia. Você só pode comparar o velocity de uma mesma equipe ao longo do tempo: se está crescendo ou diminuindo.

Escala inconsistente

Quando tarefas diferentes com a mesma complexidade recebem story points diferentes, e as mais complexas recebem menos, a escala quebra. A equipe deve calibrar a escala regularmente: a cada 3–6 sprints, revisar retrospectivamente o quanto as estimativas corresponderam à complexidade real. Isso melhora a consistência das estimativas.