Planning poker e story points

Um story point junta três coisas: a quantidade de trabalho, a complexidade técnica e a incerteza que cerca o assunto. Uma migração tediosa mas perfeitamente compreendida e uma funcionalidade pequena porém inédita podem valer 5 as duas, por motivos diferentes.

Pontos deliberadamente não são horas. No dia em que o time decide que um ponto vale quatro horas, os pontos viram uma unidade de tempo pior do que as horas e todo o benefício desaparece. A estimativa relativa funciona porque gente compara muito melhor do que prevê. Pergunte a alguém se esta user story é maior que aquela e a resposta costuma estar certa. Pergunte quantas horas vai levar e costuma estar errada.

Isso também protege o time. Um ponto não depende de quem vai pegar o card nem das interrupções da semana dessa pessoa. Ele descreve o trabalho, não quem trabalha, e isso deixa a conversa de estimativa bem menos tensa.

Escolha uma user story já terminada, de que todo mundo se lembre, e que tenha parecido pequena sem ser trivial. Chame de 2, ou de 3. É a sua âncora para o trimestre.

Daí em diante, estimar vira comparar em vez de inventar. É maior que a referência? Mais ou menos o dobro? Cada pessoa nova no time recebe a explicação da user story de referência no primeiro dia, o que é muito mais rápido do que tentar ensinar no abstrato o que “um 5” representa.

Recalibre quando a composição do time mudar de verdade, ou quando perceber que a referência não se parece mais com o trabalho atual. Nunca recalibre em silêncio no meio de um sprint: você quebraria a única série de números comparáveis que tem.

Refine antes de estimar. Uma user story sem critérios de aceite legíveis não se estima: o número obtido mediria a imaginação do time, não o trabalho. Uma sessão de refinamento produtiva responde a três perguntas: o que está sendo pedido, como saberemos que terminou, e o que continua desconhecido.

Depois estime com o time inteiro, uma rodada de planning poker por user story. A presença de quem vai fazer o trabalho não é negociável; a das outras pessoas é. Mire em dois minutos por user story e no máximo umas quinze user stories por sessão.

Por fim, anote o que foi dito, não só o número. Seis semanas depois ninguém vai lembrar por que aquela user story valia 8, e o time vai repetir a mesma discussão inteira.

Velocity é a quantidade de pontos concluídos por sprint, com média dos últimos três a cinco. O uso legítimo é previsão: a mais ou menos 30 pontos por sprint, um backlog de 120 pontos representa cerca de quatro sprints de trabalho.

Ela se desregula no instante em que vira meta. Os pontos são estimados pelas mesmas pessoas cuja performance está sendo medida: um time pressionado a aumentar a velocity vai aumentar as estimativas. O número sobe, nada sai mais rápido, e você perdeu a ferramenta de previsão de quebra. Compare um time com o próprio histórico, nunca com outro time.

Velocity irregular também não é necessariamente um problema. Olhe para ela ao longo de um trimestre: é a tendência que informa o roadmap, não o sprint isolado em que três pessoas estavam de férias.

A pergunta sempre volta, e ela é legítima: uma diretoria precisa de datas, não de pontos. A boa resposta não é recusar, é separar os dois exercícios. O time estima em pontos, porque é o que sabe fazer de forma confiável. A conversão em prazo vem depois, a partir da velocity observada, e pertence ao território da previsão, não da estimativa.

Na prática: “este lote tem 90 pontos, entregamos entre 25 e 35 por sprint, então três a quatro sprints”. A faixa é o ponto importante. Ela transmite a incerteza com honestidade, enquanto uma data única promete uma precisão que ninguém tem.

Se o assunto exige compromisso firme, aí não é mais questão de estimativa e sim de escopo: fixe a data e deixe o conteúdo negociável, ou fixe o conteúdo e deixe a data negociável. Os dois ao mesmo tempo nunca se sustentam.

Estimar no vazio. Se a user story não foi refinada, a estimativa é cara ou coroa. Refine primeiro, estime depois.

Ancorar no primeiro número dito em voz alta. É exatamente o que a revelação simultânea impede, e é por isso que estimar em uma planilha compartilhada produz números piores do que estimar com cartas.

Tirar a média de um voto dividido. Um 2 e um 13 não dão 7,5. Dão uma conversa. Discuta e revote.

Converter pontos em dias. No momento em que uma tabela de conversão circula, o time passa a estimar duração com vocabulário de tamanho, e herda as desvantagens dos dois.

Estimar tudo. Uma estimativa custa tempo de reunião e só compensa onde o número muda uma decisão. Em uma correção de uma hora ou numa tarefa que se repete todo sprint, o debate custa mais caro do que o desvio que ele corrige, e empurra o time a terminar a sessão sem ter discutido os itens que precisavam. Alguns times passam a dimensionar apenas o que carrega risco: é uma escolha legítima, não falta de disciplina.

Conduza a estimativa em si com planning poker, usando a sequência de Fibonacci assim que o backlog estiver refinado o bastante para os números significarem alguma coisa.