Para investigar essa questão, o Saint Jude analisou 727.282 issues do Jira, distribuídas em 204 projetos de software e 19 domínios diferentes. Comparamos story points com dados reais de entrega para entender se projetos que utilizavam estimativas semelhantes apresentavam também comportamentos semelhantes ao longo da execução. O objetivo não era partir da opinião de que story points funcionam ou não funcionam, mas observar o que acontece quando uma estimativa relativa começa a ser utilizada como se fosse uma métrica padronizada de entrega.

O resultado mostra uma diferença importante entre estimar uma atividade e medir o comportamento de um projeto. Story points podem fazer sentido dentro da referência criada por um time, mas isso não significa automaticamente que os mesmos valores possam ser comparados entre times, projetos ou portfólios diferentes.

Story points em horas: por que essa conversão se torna um problema

Story points são utilizados em ambientes Agile e Scrum para representar diferenças relativas entre atividades. Um time pode atribuir 1, 2, 3, 5, 8 ou 13 pontos de acordo com sua percepção de complexidade, incerteza e esforço esperado. O mais importante é que esses valores fazem sentido em relação às outras atividades estimadas pelo próprio time. Uma atividade de cinco pontos é entendida como maior, mais complexa ou mais incerta do que outra de três pontos dentro daquela mesma referência.

A dificuldade começa quando essa escala relativa é convertida em tempo. É comum ouvir perguntas como quantas horas correspondem a um story point, se cinco pontos representam um ou dois dias de trabalho ou quantos story points deveriam ser concluídos em uma sprint. Essas perguntas são compreensíveis porque gestores precisam trabalhar com prazos, capacidade e previsão de entrega, mas o próprio conceito de story point não cria uma conversão universal entre pontos e horas.

Um time pode historicamente concluir determinado tipo de atividade de cinco pontos em poucos dias, enquanto outro pode utilizar os mesmos cinco pontos para classificar um trabalho que exige muito mais tempo. A story point estimation funciona a partir da referência construída pelo time, e não a partir de uma escala comum utilizada por todas as equipes.

Se fosse possível transformar story points em uma métrica padronizada de entrega, projetos utilizando valores semelhantes deveriam apresentar tempos de execução pelo menos razoavelmente próximos. Não seria necessário que todas as atividades levassem exatamente o mesmo tempo, porque qualquer projeto apresenta variações, mas seria esperado que os números permanecessem dentro de uma faixa que permitisse utilizá-los como referência comum. Foi justamente nesse ponto que os dados começaram a mostrar um comportamento diferente.

O que os story points no Jira revelam sobre o tempo real de entrega

Começamos observando projetos cuja mediana de story points era exatamente um. Essa comparação oferece uma referência simples: se o número um tivesse um significado razoavelmente consistente entre projetos independentes, suas medianas de cycle time não deveriam estar completamente desconectadas umas das outras.

O que encontramos foi exatamente o contrário. Projetos utilizando a mesma mediana de story points apresentaram tempos medianos de entrega radicalmente diferentes.

Projeto Mediana de story points Mediana de cycle time Projeto 1 1 0,7 hora Projeto 2 1 115,5 horas Projeto 3 1 161,9 horas Projeto 4 1 197,4 horas Projeto 5 1 4.464,8 horas Projeto 6 1 8.246,3 horas

Todos esses projetos apresentam a mesma mediana de estimativa, mas seus cycle times são extremamente diferentes. Em um extremo, a mediana é inferior a uma hora. No outro, ultrapassa 8.000 horas. Mesmo quando retiramos os valores mais extremos e observamos apenas os projetos intermediários, ainda encontramos diferenças suficientes para mostrar que o número um não carrega um significado padronizado de entrega entre projetos.

Para mim, esse é um dos pontos mais importantes da análise. Um story point pode fazer sentido dentro do histórico do time que o criou, mas, quando retiramos esse número do seu contexto, ele diz muito pouco sobre quanto tempo uma atividade deveria realmente levar. A estimativa continua existindo, mas a referência que dava significado àquele número desaparece.

O mesmo padrão aparece quando os story points aumentam

A diferença não acontece apenas com atividades estimadas em um ponto. Projetos com mediana próxima de três story points também apresentaram cycle times bastante diferentes. Em um dos projetos analisados, a mediana de entrega ficou em aproximadamente 120 horas. Em outro, chegou a quase 292 horas. Um terceiro projeto alcançou aproximadamente 454 horas, mesmo utilizando a mesma mediana de story points.

Isso se torna especialmente relevante quando os story points saem do contexto do time e passam a fazer parte da governança de projetos. Um PMO pode olhar para diferentes boards do Jira e enxergar o número três em todos eles, interpretando aquelas atividades como se fossem comparáveis. Na prática, cada time pode ter criado essa estimativa utilizando referências históricas, níveis de experiência, arquiteturas, tecnologias e critérios completamente diferentes.

O problema, portanto, não está necessariamente no uso de story points para estimar uma atividade. O problema surge quando assumimos que a escala continua sendo comparável depois que atravessa as fronteiras entre times e projetos. O número continua parecendo objetivo, mas o contexto que explicava aquele número já não é o mesmo.

Story points maiores não significam automaticamente um cycle time maior

Outra parte dos dados deixa essa diferença ainda mais evidente. Encontramos projetos com uma mediana de cinco story points cujo cycle time mediano era significativamente menor do que o de projetos utilizando uma mediana de apenas um story point.

Em um dos casos, um projeto com mediana de cinco pontos apresentava cycle time de aproximadamente 140,5 horas. Outro projeto, utilizando mediana de um ponto, ultrapassava 2.000 horas. Em outra comparação, um projeto com mediana de três pontos apresentava aproximadamente 120 horas de cycle time, enquanto outro, com mediana de apenas um ponto, ultrapassava 4.400 horas.

Isso não significa que uma atividade de cinco pontos seja naturalmente mais rápida do que uma atividade de um ponto. Seria incorreto interpretar o resultado dessa maneira. O que os dados mostram é que valores absolutos de story points provenientes de projetos independentes não formam uma escala comum de tempo.

Cada time constrói sua própria referência de estimativa. Se essa referência é utilizada de maneira consistente, os story points podem continuar ajudando o time a discutir complexidade relativa e planejar suas sprints. Mas quando combinamos vários times e tratamos os valores como se todos pertencessem à mesma escala, criamos um nível de comparabilidade que os dados analisados não sustentam.

Por que a estimativa em story points se torna difícil de comparar entre times

Imagine uma organização com três times de desenvolvimento. O Time A conclui 80 story points durante uma sprint, o Time B conclui 45 e o Time C conclui 110. Quando esses números aparecem juntos em um dashboard executivo, a interpretação mais imediata pode ser que o Time C entrega mais e o Time B entrega menos.

O cálculo está matematicamente correto, mas a conclusão depende de uma suposição importante: os três times precisam estar utilizando escalas equivalentes de estimativa. Story points, porém, não foram criados para garantir essa equivalência. Uma história que recebe cinco pontos em um time pode receber três ou oito em outro, dependendo da complexidade técnica, da arquitetura, da experiência do time, da quantidade de incerteza e até dos hábitos de estimativa desenvolvidos ao longo do tempo.

Esse é um dos motivos pelos quais comparar velocity entre times pode ser tão problemático. A velocity Scrum ou Agile mostra quanto um determinado time consegue concluir dentro da sua própria referência, mas não significa automaticamente que aquele número possa ser utilizado como uma unidade universal de produtividade. Quando escalas diferentes são colocadas lado a lado, o dashboard pode criar uma sensação de precisão sem necessariamente criar uma comparação justa.

O comportamento observado nos 204 projetos reforça exatamente esse ponto. Projetos com a mesma mediana de story points podem apresentar cycle times radicalmente diferentes. Isso significa que os pontos podem carregar informação útil dentro de um contexto específico e, ao mesmo tempo, perder grande parte dessa utilidade quando agregados entre projetos independentes.

Por que story points podem se tornar um problema para o PMO

Story points normalmente surgem como uma técnica de estimativa Agile utilizada pelo time, mas em muitas organizações acabam se transformando em uma das métricas utilizadas pela gestão. Um PMO pode criar indicadores como total de story points entregues, média de pontos por sprint, velocity por time, tendências de produtividade, capacidade e comparação entre diferentes projetos.

Todos esses cálculos podem estar tecnicamente corretos e, ainda assim, levar a interpretações equivocadas. Se cada time criou sua própria escala relativa, somar os story points de vários times não transforma automaticamente esses valores em uma métrica padronizada de portfólio. Um time que entrega 100 pontos não está necessariamente produzindo duas vezes mais trabalho, valor ou resultado do que outro que entrega 50.

Os números mostram o que aconteceu segundo a referência de cada time, mas não são suficientes, sozinhos, para explicar por que um projeto está entregando mais rápido, por que outro está ficando menos previsível ou onde a capacidade está sendo consumida. Para responder a essas perguntas, precisamos analisar outros sinais produzidos durante a execução.

Para mim, é exatamente nesse ponto que Project Intelligence precisa ir além da estimativa criada no início da atividade. O valor original em story points continua sendo relevante, mas deve ser interpretado junto com aquilo que aconteceu depois: quanto tempo atividades semelhantes normalmente levaram, quantas vezes foram bloqueadas, se atravessaram várias sprints, quanto retrabalho geraram e como seu comportamento se compara ao histórico do próprio projeto.

Métricas de entrega de software para analisar além dos story points

Os dados de um projeto contêm muitos outros sinais capazes de explicar como a entrega está realmente acontecendo. O cycle time mostra quanto tempo uma atividade permanece no ciclo de entrega antes de ser concluída. O movimento entre sprints mostra quando uma atividade continua sendo carregada de uma sprint para outra. As dependências revelam quanto um trabalho precisa esperar por outras atividades, pessoas ou equipes antes de avançar, enquanto o retrabalho mostra quando algo que parecia concluído precisa voltar para execução.

As mudanças de responsável também são relevantes, porque uma atividade que troca várias vezes de ownership pode apresentar um comportamento bastante diferente de outra executada pelo mesmo responsável do início ao fim. Da mesma forma, um número elevado de transições no workflow pode indicar que uma atividade está passando por mais etapas, revisões ou mudanças do que o esperado.

Nenhum desses indicadores precisa substituir completamente os story points. O valor está justamente em analisá-los em conjunto. Uma estimativa mostra o que o time acreditava no início. Os dados de execução mostram o que realmente aconteceu depois que o trabalho começou.

Considere duas atividades estimadas em cinco story points. A primeira se comporta de maneira muito semelhante a dezenas de atividades equivalentes concluídas anteriormente pelo mesmo projeto. Seu cycle time permanece dentro da faixa histórica, não existem dependências relevantes e ela avança pelo workflow sem grandes interrupções. A segunda começa com os mesmos cinco pontos, mas fica bloqueada, atravessa diversas sprints, muda de responsável e acumula retrabalho.

As duas atividades continuam mostrando cinco story points no Jira. Mas, do ponto de vista de entrega, elas já não representam o mesmo risco.

Os dados históricos do projeto podem dizer mais do que a estimativa original

Essa é a parte da gestão de projetos que mais me interessa. Em vez de perguntar apenas quantos story points foram atribuídos a uma atividade, prefiro observar como trabalhos semelhantes se comportaram anteriormente. Quanto tempo eles normalmente levaram? Qual foi a variação entre as entregas mais rápidas e as mais lentas? Atividades com dependências apresentaram cycle times maiores? Itens que atravessaram várias sprints se comportaram de maneira diferente? Retrabalho ou mudanças de responsável apareceram antes de o tempo de entrega começar a crescer?

O histórico do projeto cria uma referência baseada naquilo que realmente aconteceu. Ele não elimina a estimativa inicial, mas adiciona contexto e permite comparar o que esperávamos com o que a execução está realmente mostrando. Se atividades semelhantes normalmente são concluídas em determinada faixa de tempo e uma nova atividade começa a se afastar rapidamente desse comportamento, temos uma informação muito mais útil do que apenas o número de pontos atribuído no planejamento.

No Saint Jude Project Intelligence, utilizamos os dados do projeto para comparar atividades atuais com o comportamento histórico do próprio projeto e com atividades semelhantes já concluídas. A Inteligência Artificial ajuda a identificar combinações de sinais, desvios e padrões recorrentes que seriam difíceis de perceber olhando apenas para um único campo do Jira ou para um relatório isolado de sprint.

O objetivo não é substituir o gerente de projetos ou criar uma nova escala de estimativa. O objetivo é criar uma camada de inteligência que ajude PMOs e líderes a compreender se as atividades atuais continuam se comportando de maneira consistente com trabalhos semelhantes, se a execução começou a sair do padrão histórico e se as premissas utilizadas no planejamento ainda fazem sentido diante dos dados disponíveis hoje.

O que 204 projetos no Jira realmente mostram sobre story points?

Depois de analisar 727.282 issues do Jira e comparar story points com medianas de tempo de entrega em 204 projetos de software, os dados não sustentam o uso de story points como uma métrica universal de entrega de projetos. Projetos com a mesma mediana de pontos podem apresentar cycle times radicalmente diferentes, enquanto projetos utilizando medianas maiores podem, em determinados casos, entregar muito mais rapidamente do que projetos utilizando valores menores.

Por causa dessa variação, a análise não fornece base para afirmações como “um story point equivale a X horas” ou “um time que entrega 100 story points é duas vezes mais produtivo do que um time que entrega 50”. As duas afirmações dependem de story points funcionando como uma unidade padronizada, e não é isso que observamos quando diferentes projetos são comparados.

Story points são relativos por definição. Essa característica pode torná-los úteis dentro da referência criada por um time, mas também torna muito difícil utilizá-los como uma métrica padronizada entre equipes, projetos ou estruturas de governança corporativa.

Para mim, a pergunta mais útil deixa de ser quantas horas uma atividade de cinco pontos deveria levar. A pergunta passa a ser: considerando o histórico deste projeto e o comportamento de atividades semelhantes, o que seria razoável esperar desta atividade agora?

É nesse momento que uma estimativa começa a se transformar em Project Intelligence. O story point continua sendo uma informação importante, mas se torna muito mais útil quando é interpretado junto com o comportamento real da entrega, os dados históricos e os demais sinais produzidos pelo projeto durante sua execução.

Quer entender o que os dados do seu Jira estão mostrando?

Story points são apenas um dos sinais existentes dentro de um projeto. O Saint Jude analisa dados de projetos para identificar padrões relacionados a tempo de entrega, riscos, dependências, retrabalho, capacidade e previsibilidade, combinando as estimativas originais com o comportamento histórico observado durante a execução.

Você pode enviar os dados do seu projeto e receber uma análise gratuita por meio do nosso Project Health Checker. A ideia é utilizar os dados que o projeto já produz para entender não apenas aquilo que deveria acontecer, mas como a execução está realmente se comportando e quais sinais merecem atenção antes de se transformarem em problemas maiores.

Até a próxima!

Erik Scaranello