O que são pontos de história? Estimando o esforço, não o tempo

Os pontos de história medem o esforço relativo, a complexidade e a incerteza do trabalho — e não as horas. Como estimar o tamanho em relação a uma história de referência e as dúvidas que costumam confundir as equipes.

Os pontos de história medem o esforço relativo de uma tarefa — seu tamanho, complexidade e incerteza reunidos em um único número — e não as horas que ela levará. Você avalia o tamanho de um item do backlog comparando-o a uma história de referência que a equipe já entregou (“esse tem mais ou menos o dobro daquele”), em vez de adivinhar uma duração. Essa simples mudança é o que faz com que a estimativa resista ao contato com a realidade.

Por que medir o esforço, e não o tempo?

Uma equipe que faz estimativas em horas, na verdade, está trabalhando com 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. As pessoas não são confiáveis quando se trata de “quanto tempo isso vai levar”, mas são surpreendentemente boas em avaliar “isso é maior do que o que concluímos no último sprint?”. Os story points se baseiam nessa segunda abordagem.

Dimensionamento relativo permite que a equipe chegue a um consenso de que um item é maior do que outro sem que ninguém se comprometa com um número de horas — o que evita o viés de ancoragem e de antiguidade que as estimativas em horas tendem a gerar. O número resultante não representa uma duração; trata-se de uma posição em uma escala compartilhada.

A balança e para que servem os pontos

A maioria das equipes vota em uma escala do tipo Fibonacci — 1, 2, 3, 5, 8, 13 — em uma rodada de planning poker. As diferenças aumentam propositalmente: quanto maior o trabalho, menos se sabe de fato, então a escala deixa de fingir que é possível distinguir um 9 de um 10. Some os pontos que uma equipe acumula ao final de cada sprint e você obtém a velocidade — que é exatamente o que os pontos de previsão se destinam a produzir.

O maior motivo de fracasso é a equipe que começa a converter pontos de volta em horas. No momento em que essa tabela de conversão é publicada no wiki, todas as conversas sobre estimativas se transformam em discussões sobre duração, e a noção de esforço relativo se perde.

Qual obra você deve indicar?

Há duas perguntas que sempre surgem em todas as reuniões de refinamento: isso dá pontos mesmo? E, se sim, quantos? A escala serve justamente para responder à pergunta “quantos”. Já para a pergunta “isso dá pontos?”, existe uma regra prática: atribua pontos a tudo o que a equipe entregar como parte do trabalho comprometido, para que o indicador de velocidade reflita para onde a capacidade realmente é direcionada.

Erros

Um bug com causa conhecida e uma correção clara é considerado uma história. Ele possui critérios de aceitação (“o formulário não aceita mais quantidades negativas”), um escopo definido e um tamanho razoável — portanto, vote nele como em qualquer outra história. O trabalho com bugs e o trabalho com recursos disputam a mesma capacidade, e a velocidade deve refletir isso.

A exceção é o bug cuja natureza é “ainda não sabemos o que há ali” — investigar a corrupção de dados, descobrir por que o p99 dobrou, os clientes continuam relatando o problema e não conseguimos reproduzi-lo. A correção não tem dimensão definida porque a causa é desconhecida; portanto, uma votação em story points apenas mede o que a equipe espera descobrir. Coloque esses casos em uma trilha de investigação com prazo definido: dedique um ou dois dias à investigação e, depois, volte com uma história concreta sobre o que quer que você tenha descoberto.

Testes e Controle de Qualidade

Os story points dimensionam o trabalho entre o momento em que “a história entra no sprint” e o momento em que “a história está pronta para entrega” — o que inclui todos os testes de controle de qualidade que a equipe realiza como parte do “concluído”: testes automatizados, verificação manual, verificações de acessibilidade e revisão de segurança. A história não está concluída quando o PR é mesclado; ela está concluída quando atende à definição de concluído.

As equipes que destinam o trabalho exclusivamente ao desenvolvimento e acrescentam o controle de qualidade (QA) separadamente acabam assumindo compromissos excessivos a cada sprint, pois o QA é o gargalo que ninguém levou em conta. Se uma equipe separada de controle de qualidade (QA) for responsável pelos testes, a tarefa ainda arca com o custo do lado do desenvolvimento de trabalhar com ela — preparar a compilação, elaborar o plano de testes, responder a perguntas. Essa parte não é gratuita, portanto, permanece na estimativa.

Por que você raramente quer uma matéria de apenas um ponto

Os pontos são relativos; portanto, um 1 só faz sentido quando comparado a um 2, um 3 ou um 8. Quando uma equipe tem uma sequência constante de histórias de 1 ponto, esse gradiente desaparece — tudo que é insignificante é um 1, tudo que é maior é um 2 ou um 3, e a escala se reduz a um lance de moeda.

A solução não é proibir os “1s” — essa é a versão simplista e superficial da regra. É perguntar por que tanto trabalho está ficando na parte inferior da escala. Normalmente, a história de referência se deslocou: a equipe ficou mais rápida, e o “1” original agora é menor do que qualquer coisa que eles entregam; então, escolha uma referência mais recente que a equipe se lembre e redefina o ponto de referência. Às vezes, a equipe está decompondo demais durante o refinamento, separando cada critério de aceitação como se fosse uma história própria — “atualizar o texto do botão” não é uma história, é um critério de aceitação de uma história maior. E, às vezes, o trabalho é realmente pequeno (uma tarefa de manutenção, uma alteração de texto que precisa de revisão jurídica, um ajuste de configuração que afeta a produção); nesse caso, os pontos estão cumprindo sua função e não há nada a corrigir.

O indicador a ser observado não é “nunca ter histórias com classificação 1”. É o fato de as histórias com classificação 1 constituírem a maior parte da fila de tarefas. Uma ou duas por sprint está tudo bem. Se a cada duas histórias houver uma com classificação 1, isso significa que já faz muito tempo que a questão da calibração não é discutida.

Perguntas frequentes

O que são pontos de história no ágil?

Os pontos de história são uma unidade de estimativa relativa: um número que reflete a magnitude de uma tarefa — considerando em conjunto o esforço, a complexidade e a incerteza — em comparação com uma história de referência que a equipe já tenha concluído. Eles não são, deliberadamente, uma medida de tempo. A equipe avalia o tamanho de cada item em relação aos demais, e não em relação ao tempo.

Os bugs deveriam ter pontos de história?

Sim, quando o bug tem uma causa conhecida e uma correção clara — trata-se de uma tarefa como qualquer outra, e identificá-la mantém a velocidade alinhada com o destino da capacidade. A exceção é o bug exploratório cujo escopo ainda não é possível definir; coloque-o em uma trilha de investigação com prazo definido e avalie o tamanho da correção real assim que souber a causa.

Os story points incluem os testes?

Sim. Os pontos determinam todas as etapas entre o momento em que uma funcionalidade entra no sprint e o momento em que ela está pronta para ser lançada, o que inclui os testes e o controle de qualidade que a equipe realiza como parte de sua definição de “concluído”. Se os pontos forem atribuídos apenas ao trabalho de desenvolvimento, o sprint sempre ultrapassará o prazo, pois o controle de qualidade é o gargalo que ninguém levou em conta.

Por que você deve evitar matérias de um único ponto?

Algumas estão bem. Mas se a maior parte do backlog for composta por 1s, a história de referência da equipe se desviou e a escala entrou em colapso — tudo passa a ser visto como “minúsculo ou maior”. Recalibre com base em uma história de referência recente, em vez de reduzir a escala.

Leituras relacionadas