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 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 pontos de história 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 costumam gerar. O número resultante não é uma duração; é uma posição em uma escala compartilhada.

Avaliar o esforço em vez de horas evita três problemas que sempre acompanham as estimativas baseadas em horas:

• Uma estimativa não é um compromisso. As horas levam as partes interessadas a tratar “8 horas” como uma promessa; os pontos mantêm a estimativa como uma previsão.
• A mesma tarefa leva um tempo diferente para pessoas diferentes. A pontuação reflete o trabalho, não a pessoa.
• A duração não leva em conta o risco. Uma tarefa curta, mas incerta, pode ser mais arriscada do que uma longa e bem compreendida; por isso, os pontos refletem essa incerteza.

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.

Se um item for maior do que, digamos, um 13, isso geralmente significa que a escala está indicando que você deve dividi-lo em partes que a equipe consiga entender e concluir dentro de um único sprint.

Para uma primeira passagem mais rápida e aproximada, algumas equipes classificam todo o backlog em tamanhos de camiseta e convertem apenas o trabalho de curto prazo em pontos, uma vez que ele seja refinado.

Em uma rodada de planning poker, todos revelam suas cartas ao mesmo tempo, para que ninguém se deixe influenciar pela voz mais alta ou pela pessoa com mais tempo de casa. Quando as estimativas mais altas e mais baixas divergem, essas duas pessoas explicam seu raciocínio, e essa conversa — que traz à tona as suposições e a complexidade oculta por trás do número — geralmente vale mais do que o próprio número. O guia completo do planning poker aborda a mecânica do jogo.

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 discussões sobre estimativas se transformam em uma discussão 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 é uma tarefa. 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 tarefa. 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 itens em uma trilha de investigação com prazo definido: dedique um ou dois dias à investigação e, em seguida, volte com uma história concreta sobre o que quer que tenha sido 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 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 um fluxo constante de histórias de 1 ponto, esse gradiente desaparece: tudo que é pequeno é 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 “1” (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; portanto, 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 itens com pontuação 1”. É o fato de os itens com pontuação 1 constituírem a maior parte da lista de pendências. Um ou dois por sprint está tudo bem. Se a cada duas histórias houver uma com pontuação 1, isso significa que a questão da calibração não vem sendo discutida há muito tempo.

Pontos de história e a retrospectiva

A estimativa é um dos aspectos mais comuns que uma equipe analisa em sua retrospectiva de sprint. Quando os itens são rotineiramente subestimados ou superestimados, quando a velocidade oscila drasticamente ou quando o trabalho “concluído” continua sendo reaberto, a retrospectiva é o momento em que a equipe recalibra sua percepção compartilhada do tamanho das tarefas e aprimora a forma como divide o trabalho. A precisão da estimativa melhora por meio desse ciclo de feedback, e não por se esforçar mais logo no início.

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 (seu esforço, complexidade e incerteza, em conjunto) 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.

Por que usar pontos de história em vez de horas?

As pessoas têm dificuldade em estimar o tempo absoluto, mas são boas em avaliar se uma coisa é maior do que outra, e os story points se baseiam nesse ponto forte. Eles também evitam a armadilha de tratar uma estimativa como um compromisso, levam em conta o fato de que a mesma tarefa leva tempos diferentes para pessoas diferentes e incorporam complexidade e risco, não apenas a duração. Ao longo de alguns sprints, a velocidade de uma equipe em pontos torna-se uma previsão mais confiável do que a soma das estimativas em horas.

Como você estima os pontos de história?

A maioria das equipes utiliza o “planning poker”. Alguém explica um item do backlog, a equipe o discute e todos escolhem, em particular, um valor a partir de uma escala compartilhada, geralmente uma sequência do tipo Fibonacci (1, 2, 3, 5, 8, 13). Todos revelam suas escolhas ao mesmo tempo; quando as estimativas divergem muito, quem deu a nota mais alta e quem deu a mais baixa explicam seu raciocínio, e a equipe volta a votar até que haja convergência. A discussão que traz à tona complexidades ocultas costuma ser mais valiosa do que o próprio número.

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 real da capacidade. A exceção é o bug exploratório cujo escopo ainda não pode ser definido; 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 avaliam 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?

Alguns estão bem. Mas se a maior parte do backlog for de 1, a história de referência da equipe se desviou e a escala entrou em colapso, de modo que tudo parece minúsculo ou maior. Recalibre com base em uma história de referência recente, em vez de reduzir a escala.

É possível comparar os story points entre equipes?

Não. Um story point é calibrado de acordo com a percepção de tamanho relativo de uma determinada equipe; portanto, o valor 5 de uma equipe não é o mesmo que o 5 de outra. Comparar a velocidade ou os totais de pontos entre equipes não faz sentido e, quando usado como meta, é prejudicial: isso leva as equipes a inflar as estimativas. Os pontos de história são uma ferramenta de planejamento para as próprias previsões de uma única equipe, não uma métrica de produtividade para comparação.

Leituras relacionadas

• Por que os story points utilizam a sequência de Fibonacci: por que as diferenças aumentam à medida que os números crescem.
• Pontos de história x horas: a armadilha da conversão e o que fazer quando alguém precisa de uma data.
• Velocity: transformar pontos de inflexão em uma previsão sem alterá-los.
• Técnicas ágeis de estimativa: qual método usar em cada situação e quais são as limitações de cada um.
• Retrospectiva de sprint: onde as equipes reajustam as estimativas que sempre ficam erradas.
• Guia de estimativa ágil: o conjunto completo, do planning poker à divisão de histórias.
• Planning Poker gratuito para equipes ágeis: avaliem juntos o tamanho do backlog em tempo real.