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.

Points and hours as orthogonal axes Duration (hours) Relative effort (points) reference story (the one everyone shipped) story A same size, junior dev story B same size, senior dev "1 point = 4 hours" collapses both axes
Dois textos com o mesmo tamanho em pontos podem levar tempos diferentes para serem lidos. A linha de conversão finge que isso não é possível.

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