Story points sem mistério

Story points, ou pontos de história, medem o tamanho de uma tarefa em relação às outras tarefas do mesmo time. Não existe “um ponto” universal. Quando o time diz que a integração com o novo meio de pagamento vale 8, está dizendo que ela é bem maior que aquele ajuste de 3 pontos da semana passada e um pouco menor que a migração que levou 13. Fora desse time, o 8 não quer dizer nada. Em times Scrum e XP, os pontos costumam ser a unidade mais comum de estimativa ágil.

O que cabe dentro de um ponto

Uma estimativa em pontos mistura três coisas.

• Esforço. A quantidade de trabalho mesmo. Migrar 40 telas para o novo design system é muito trabalho, mesmo sem nada difícil em nenhuma delas.
• Complexidade. Quão difícil é acertar. O cálculo de impostos de uma nota fiscal eletrônica pode ter poucas linhas de código e ainda assim exigir horas de leitura da legislação e muitos casos de teste.
• Incerteza. O que o time ainda não sabe. A API de um banco parceiro sem ambiente de testes, uma regra de negócio que “depende do jurídico”, um sistema legado em COBOL que só uma pessoa da empresa entende. Quanto mais desconhecido, maior o número.

Não existe fórmula que combine os três. Cada pessoa pesa esses fatores do seu jeito. Numa história de emissão de NF-e, o Lucas pode votar 5 porque vê dezenas de campos para mapear, e a Camila pode votar 5 porque sabe que o ambiente de homologação da SEFAZ cai com frequência. Se ninguém perguntar, o 5 vai para o backlog e o risco da SEFAZ fica só na cabeça da Camila. No planning poker os extremos explicam o voto depois da revelação, mas aqui não houve extremo. Por isso, quando o número bate e a história é arriscada, vale perguntar o motivo de cada um antes de anotar.

Por que não estimar direto em horas

A pergunta aparece em todo time que começa: se no fim a gestão quer saber “quando fica pronto”, por que não estimar logo em horas?

No Brasil, boa parte do desenvolvimento acontece em consultorias e fábricas de software que vendem horas para o cliente. Nesse ambiente, uma estimativa em horas vira rapidamente um valor na proposta, e cada estouro vira cobrança: “estava estimado em 16 horas, por que levou 30?”. Com medo dessa conversa, as pessoas passam a estimar com gordura e a esconder risco. Um número que descreve tamanho, e não prazo, deixa mais espaço para alguém dizer “não sei se essa integração funciona”.

Horas também pressupõem alguém fazendo o trabalho. Em muitos times as tarefas são puxadas do board por quem fica livre primeiro, e no refinamento ninguém sabe quem vai pegar cada uma. Uma estimativa em horas precisa supor uma pessoa, e quase sempre a suposição é a mais otimista: a de que vai pegar quem conhece melhor aquele código. A sprint nasce apertada. Pontos deixam essa escolha para a planning.

Há ainda um efeito menos óbvio. Para dizer “12 horas”, a pessoa precisa imaginar a solução em detalhe: quais classes mexer, quais testes escrever. A sessão de estimativa vira uma reunião de design, e cada história leva vinte minutos. Para dizer “parece com aquela de 5”, basta entender o problema.

Por fim, as referências dão estabilidade à escala. Uma estimativa em horas feita numa segunda-feira tranquila sai diferente da feita numa sexta de deploy, porque depende de como a pessoa imagina a própria semana. Já a pergunta “parece mais com a exportação de CSV ou com a troca de endereço?” tem sempre as mesmas histórias como apoio, e um 5 de março continua comparável com um 5 de agosto.

Histórias de referência

Antes da primeira sessão, escolha algumas histórias que o time já entregou e lembra bem, e dê valor a elas.

Um time de e-commerce poderia usar, por exemplo:

• 1 ponto: trocar o texto e o link do rodapé do e-mail de confirmação de pedido.
• 3 pontos: exportar os pedidos do dia em CSV para o financeiro, com filtro por status.
• 8 pontos: permitir que o cliente troque o endereço de entrega depois de fechar o pedido, com recálculo do frete.

A partir daí, cada história nova é posta ao lado dessas: parece mais com a exportação ou com a troca de endereço? Prefira histórias que o time inteiro acompanhou e que não tiveram grandes surpresas no caminho. Anote-as na descrição do board: quem entrar no time depois vai aprender por elas o que vocês chamam de 3.

Velocity: para que servem os pontos

Velocity é a soma dos pontos das histórias que o time terminou numa sprint, segundo a definição de pronto do próprio time. A história com o PR aberto esperando revisão na sexta à tarde não entra na conta dessa sprint; entra na da sprint em que for concluída.

O número de uma sprint isolada varia demais para servir de base. Imagine um time que fechou 31, 26, 34 e 29 pontos nas últimas quatro sprints. A faixa de 26 a 34 é o que ele usa para decidir quanto puxar na próxima planning. E serve também para previsão: se ainda faltam 90 pontos para o lançamento do novo app, o time pode dizer à PO que, no ritmo das melhores sprints, são três; no ritmo da pior, quatro.

Estimativas individuais erram, mas costumam errar para os dois lados, e numa sprint inteira parte disso se anula. O que atrapalha de verdade são mudanças de contexto: gente entrando e saindo do time, uma sprint engolida por incidentes de produção, a escala mudando aos poucos sem ninguém combinar. Quando o time sabe que uma dessas mudanças vem aí, como a chegada de duas pessoas novas, vale avisar a PO de que as próximas duas ou três sprints servem pouco para previsão.

Como a velocity entra no refinamento e na Sprint Planning está na página de scrum poker.

Mitos que atrapalham

“Um ponto é um dia de trabalho”

Mais cedo ou mais tarde alguém propõe uma tabela: 1 ponto igual a 4 horas, 2 pontos igual a um dia. O problema é que ela congela uma relação que muda o tempo todo. Quando entram duas pessoas novas ou a sprint enche de incidentes, o time passa a entregar menos pontos, e a velocity registra isso na sprint seguinte. A tabela continua prometendo 4 horas por ponto até alguém lembrar de revisá-la, e nesse meio-tempo toda data calculada com ela sai otimista.

“Story point é a mesma coisa que ponto de função”

No Brasil a confusão é comum, porque a análise de pontos de função aparece muito em contratos, principalmente com o setor público. Ponto de função é uma métrica padronizada de tamanho funcional, contada com regras formais e comparável entre projetos. Story point é uma escala particular de um time, sem regra de contagem. Um não converte no outro.

“Dá para comparar squads pela velocity”

A squad de pagamentos fecha 45 pontos por sprint, a de catálogo fecha 22. Isso não diz qual das duas entrega mais, porque cada uma construiu sua escala a partir das próprias referências. Se a diretoria começar a cobrar a squad de catálogo pelo número, as estimativas dela vão engordar em poucas sprints. A comparação que interessa é outra: cada squad contra ela mesma, ao longo do tempo.

“Pontos medem o desempenho de cada pessoa”

Somar os pontos que cada desenvolvedor fechou no trimestre e levar isso para a avaliação de desempenho é um jeito rápido de estragar a estimativa. As pessoas passam a disputar histórias “bem pontuadas”, param de ajudar colegas travados e começam a votar alto.

Como começar

Um jeito simples de montar a primeira escala é uma sessão de calibração de uma hora. Separe umas dez histórias que o time entregou nos últimos meses, de tamanhos variados, e peça que o time as ordene da menor para a maior num quadro, sem falar em números. Discordâncias sobre a ordem já rendem boas conversas. Depois, marque a menor que ainda dá algum trabalho como 1 ou 2 e distribua as outras pelo baralho padrão (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, mais “?” e ☕; o motivo dos saltos está na página do baralho Fibonacci). Três dessas histórias viram as referências oficiais.

Na primeira sessão de planning poker de verdade, pontue só o que deve entrar na próxima sprint e um pouco de folga. Pontuar o backlog inteiro de uma vez cansa e produz números em que ninguém confia. Uma sala online, grátis e sem cadastro, resolve a parte das cartas.

Nas primeiras sprints, a velocity vai oscilar bastante. Espere juntar três ou quatro antes de usá-la para dizer quanto cabe numa sprint, e mais algumas antes de fazer previsão para alguém de fora do time. De tempos em tempos, abra as referências de novo e confira se elas ainda representam o que o time chama de 1, 3 e 8.