Pontos de história x horas: por que convertê-los é uma armadilha
Os pontos de história medem o esforço relativo; as horas medem a duração — são eixos diferentes. Se você criar uma tabela de conversão de pontos para horas, sem perceber, estará voltando a estimar o tempo.
Se você consegue converter pontos em horas, está estimando o número de horas.
Pontos de história e horas não são unidades diferentes da mesma coisa. As horas medem a duração — quanto tempo algo vai levar para você concluir. Os pontos medem o esforço relativo — o tamanho da tarefa em comparação com a história de referência que todos já entregaram. São eixos diferentes. No momento em que você escreve “1 ponto = 4 horas” no wiki, você transforma toda conversa sobre estimativas em uma discussão sobre duração e descarta a propriedade de esforço relativo que a técnica existe para lhe proporcionar.
O motivo pelo qual as equipes recorrem à conversão é concreto: alguém de fora da equipe precisa de uma data, e os pontos não têm unidades. A solução não é uma tabela de conversão; é velocity. O velocity já mapeia pontos para tempo no nível da equipe — pontos por sprint × número de sprints resulta em uma data que reflete a taxa de entrega real da equipe, e não uma fictícia.
Por que é que os pontos existem, afinal?
Uma equipe que faz estimativas em horas, na verdade, faz duas estimativas: aquela em que o engenheiro sênior acredita e aquela que o engenheiro júnior anota depois de arredondar para cima, para parecer responsável. Votos ocultos e esforço relativo contornam ambas. Os pontos permitem que a equipe concorde que “isso é maior do que aquele que lançamos” sem precisar concordar que “isso vai me levar quatro horas” — e a discordância que surge na revelação é onde o escopo oculto vem à tona.
Como é o que é bom
Uma equipe que utiliza bem os pontos não fala em horas durante a sessão. Ela fala sobre a história de referência, o trabalho comparável que já entregou e as incógnitas. O número resultante é um indicador de esforço relativo que a equipe — e somente a equipe — pode transformar em uma data por meio de sua própria velocidade.
”Mas quanto tempo vai demorar?”
Essa é a necessidade legítima que se esconde por trás de cada solicitação para converter pontos em tempo, e ela merece uma resposta concreta — um intervalo de datas com base na velocidade. Se sua equipe tem uma média de 30 pontos por sprint de duas semanas, uma fatia de 60 pontos do backlog equivale a aproximadamente dois sprints, e você comunica isso como “cerca de um mês, dependendo do que conseguirmos realizar”. Essa é uma data que já leva em conta os fatores de variabilidade da equipe — as reuniões que realmente acontecem, a escala de plantão, os feriados. A conversão de pontos em horas fornece uma data sem esses fatores de variabilidade, o que é, com maior certeza, incorreto.
Portanto, acompanhe a velocidade, faça projeções com base nela e recalcule-a a cada alguns sprints. Essa é a maneira correta de converter pontos de virada em tempo, e não requer nenhuma tabela de conversão. O tempo de ciclo é outra questão: uma história de 3 pontos ainda pode ficar em revisão por uma semana, o que é um problema de fluxo, não de estimativa.
Os story points incluem os fins de semana?
Não — porque os pontos não levam em conta o tempo de forma alguma. Um 5 não equivale a 40 horas; significa “isso é maior do que a história de referência”. Se a equipe trabalha nos fins de semana, tira as sextas-feiras de folga ou tem semanas de quatro dias, isso não influencia a estimativa, pois a estimativa não é uma medida de tempo no calendário.
Onde os fins de semana realmente fazem diferença é na velocidade. A velocidade é medida em pontos por sprint, e a duração do sprint é medida em tempo de calendário — portanto, uma equipe que tenha um feriado no meio do sprint registrará uma velocidade menor nesse sprint, pois teve menos horas de trabalho para dedicar o mesmo esforço. É aí que os fins de semana devem aparecer: na camada do calendário, não na camada dos pontos. Os pontos não têm fins de semana. A velocidade, sim.
Desative a tabela de conversão. Em vez disso, faça a projeção a partir da velocidade.
Perguntas frequentes
Quantas horas correspondem a 3 pontos de história?
Não há uma resposta fixa, e é justamente isso que importa. Os pontos de história medem o esforço relativo, não a duração — 3 pontos significam “um pouco maior do que nossa história de referência”, o que leva tempos diferentes para equipes diferentes. Faça a conversão no nível da equipe por meio da velocidade, nunca por história.
1 ponto de história equivale a 1 dia?
Não. Um ponto de história não é, de forma alguma, uma unidade de tempo. Se sua equipe adotou a regra de “1 ponto = 1 dia”, você está fazendo estimativas em dias com um verniz de Fibonacci — e perdeu o sinal de esforço relativo que os pontos existem para lhe fornecer.
Por que usar pontos de história em vez de horas?
Porque a equipe pode concordar que “isso é mais complexo do que aquilo” sem precisar concordar que “isso vai me levar quatro horas”. Os votos anônimos, aliados ao dimensionamento relativo, evitam os vieses de ancoragem e de antiguidade que as estimativas de horas tendem a gerar — e a velocidade ainda fornece uma data quando você precisar dela.
É possível converter pontos de história em horas?
Somente no nível da equipe e somente a posteriori: os pontos concluídos por sprint (velocidade) correspondem ao tempo de calendário para aquela equipe específica. Uma tabela fixa do tipo “X pontos = Y horas” por história é a forma errada de proceder — descarte-a.
Os story points incluem os fins de semana?
Não — porque os pontos não levam o tempo em consideração. Um 5 significa que a tarefa é “maior do que a história de referência”, e não um número de dias. Fins de semana, feriados e semanas de quatro dias são refletidos na velocidade (pontos por sprint), que é baseada no calendário, e não nos pontos em si.
Leituras relacionadas
- O que são pontos de história? — esforço relativo, não tempo, explicado desde o início.
- Velocity — a única maneira correta de converter pontos em uma data.
- Planejamento de velocidade e capacidade — usar essa previsão para definir o tamanho de um sprint realista.
- Guia de estimativa ágil — o conjunto completo de recursos sobre estimativa.
- Planning Poker gratuito para equipes ágeis — faça estimativas em pontos, em conjunto e em tempo real.